In general what happens here if there is not an Okta session is that you will need to authenticate on your Okta org and then we will continue with the flow, which should include your application context. If it does not then there may be a situation of the page refreshing during the process if we’re routing you through an IdP you have set up or the possibility that the OIDC flow is being interrupted and we’re seeing it as a new flow and using the default destination. Log analysis can help determine which case is happening, but you can also set a default app in your Okta org to help take care of this: Set up a default app redirect | Okta
If none of these suggestions help with your use case please feel free to reach out on the Okta Help Center (Lightning) and open up a case so we can go over the information on this and better assist you.
Hi @daniel.sanders, thanks for the suggestions! Unfortunately, I haven’t been able to make any progress here. To clarify, the goal of my app would be to have users set up SSO themselves (and connect to their own SSO providers), so setting up a default app redirect in my Okta doesn’t make sense.
I’m using this guide to initiate SSO in my app. I haven’t modified the core parts of the code, but when I go to the authorization URL and sign in, I run into the issue where Okta doesn’t redirect back to my app. This happens with both username/password login and Google OAuth. Given that the redirect only works when I’m already signed in, I want to say that the flow is being interrupted when I login, but I’m not sure why. Any thoughts here?
I’m also unable to open a case in the Okta Help Center. It says I’m a “Community Only User.”
Perhaps this is more helpful. This is the chain of redirects:
Navigated to http://localhost:3000/login?callbackUrl=http%3A%2F%2Flocalhost%3A3000%2F
Navigated to https://dev-<id>.okta.com/app/<...>/sso/saml?SamlRequest=<...>&RelayState=<...>
Navigated to https://accounts.google.com/o/oauth2/auth?state=<...>&client_id=<...>&redirect_uri=https%3A%2F%2Fokta-devok12.okta.com%2Foauth2%2Fv1%2Fauthorize%2Fcallback&response_type=code&scope=email+openid+profile
Navigated to https://dev-<id>.okta.com/oauth2/v1/authorize/callback?code=<...>&state=<...>
Navigated to https://dev-<id>-admin.okta.com/admin/getting-started
What is the exact sequence of requests (preferable the actual endpoints you see being hit on the Okta domain and your application) when you see this behavior? What is your application doing to log the users in?
For some reason, my posts are being marked as spam. My guess is because I was including URLs in them, so I’ve decided to shorten everything.
Here is what the navigation looks like when I’m not already logged in:
# First, we login via WorkOS
Okta DevOK12 /sso/idps/<id>
# A bunch of Google OAuth endpoints
Okta DevOK12 /oauth2/v1/authorize/callback
Okta DevOK12 /oauth2/v1/authorize
# Okta endpoints that lead me to the admin dashboard
Hopefully, this is comprehensive enough. Let me know if there’s any other information needed.
On a different note, I just tested again and logging in via username/password redirects properly back to my app. However, logging in via Google OAuth still doesn’t redirect properly. Not sure if logging in via Google OAuth disrupts the flow somehow.
So looking into things a bit more, it seems like the Google OAuth flow is disrupting the WorkOS flow.
WorkOS initiates SSO with the correct callback URL, and I have to log into Okta as part of that flow. If I choose Google OAuth, the new OAuth flow “replaces” the WorkOS flow. This new flow has its own callback URL (aka the admin dashboard), and when I successfully login, I get redirected there.
On the WorkOS end, the logs say that the authentication session has been initiated but never completed, meaning that Okta never tells WorkOS that authentication has finished. Ideally, the new flow would return control back to the old flow so the original login can proceed, but I’m not sure if that’s possible.