Hi Descopers. Im building some internal auth feat...
# ask-a-descoper
a
Hi Descopers. Im building some internal auth feature in which on some cases i want to redirect the customer to descope auth flow (the descope hosted solution). however when the customer finishes the flow i want to redirect him back to my service. is there a way to controll the post flow redirect url via some query parameter or something?
r
Hi Asaf, Yes, when using Descope's Auth Hosting Application, you can control the redirect behavior through configuration. When deploying or integrating the Auth Hosting App, you can use query parameters to customize the authentication experience Doc. The app is accessed at
<https://auth.descope.io/><YOUR_PROJECT_ID>
. Doc However, for post-authentication redirects back to your service, you need to configure Approved Callback URLs in your application settings Doc. These are the URLs Descope is allowed to redirect users to after authentication Doc. The redirect URI must be pre-registered with Descope for security reasons - you cannot use arbitrary redirect URIs via query parameters alone. The URI you use must be on the list of approved URIs, and all components (scheme, subdomain, domain, path, port) must match exactly Doc.
a
i might be missing something but i dont see anything in the doc about redirect uri šŸ˜ž my uri is already approved.
r
Did you check this https://www.descope.com/blog/post/redirect-uri-client-credentials And are facing any error in your current flow?
a
i fear im not explaining myself correctly. im not using oidc my plan is to somewhere along these lines: 1. User accesses the api 2. Verify user has a valid jwt in the DS cookie 3. if not, redirect to
<https://auth.descope.io/><YOUR_PROJECT_ID>?flow=<some_flow>
4. user does all flow and authenticates, redirected back to app with SET_COOKIE header for the DS cookie. 5. user passes auth in my app. does that sounds reasonable? my issue is between step 3 and 4 where i fail to redirect the user back to my app.
*between 4 and 5 sorry šŸ™‚
r
Hi @Asaf Rosentswaig Let me check how you can archive your use case
šŸ™ 1
Can you confirm your frontend tech stack so I can give you working solution based on your frontend
a
im trying to avoid a FE here. this logic will happen in my ingress before we reach the FE
i plan to write this logic in go if that matters.
r
Okay got it let me check
šŸ™ 1
Your approach will work with Descope's Auth Hosting Application. Here's how to implement it: Flow Setup: 1. User accesses your API 2. Check for valid JWT in DS cookie 3. If not authenticated, redirect to
<https://auth.descope.io/><YOUR_PROJECT_ID>?flow=<flow_id>
Doc 4. User completes the flow 5. Descope sets the DS cookie and redirects back to your app Key Configuration: If your project settings are configured to manage session tokens in cookies, Descope services will automatically set the session token in the DS cookie as a Secure and HttpOnly cookie Doc. This means the session token will be stored in the browser and will be accessible for authentication checks. You'll need to configure your redirect URI in the Descope console. The redirect URI must be pre-registered and match exactly (including scheme, subdomain, domain, path, and port) Doc. Available Query Parameters: When redirecting to the Auth Hosting App, you can use: • `flow`: Specifies which authentication flow to run (e.g.,
?flow=login
) • `tenant`: For multi-tenancy scenarios (e.g.,
?tenant=example_tenant
) • `bg`: Changes background color or image • `debug`: Shows detailed flow errors in console • `style`: Runs a specific style for your application • `theme`: Enforces a specific theme After authentication, Descope will redirect back to your configured callback URL with the DS cookie set, allowing your API to verify the JWT on subsequent requests.
a
thanks! is there an option to have a dynamic redirect uri? i would like to return the user to the originally requested page
r
Redirect URIs must be pre-registered with Descope for security reasons - you cannot use arbitrary redirect URIs dynamically. The URI you use must be on the list of approved URIs, and all components (scheme, subdomain, domain, path, port) must match exactly.