Preserve the state of a nested oidc flow

Questions OAuth/OIDC
1

hello all,

I have the following scenario:

  1. user arrives on site A and wants to login
  2. site A initiates an OIDC flow with OKTA and arrives to OKTA’s login page
  3. on OKTA’s login page, the user initiates another OIDC login flow with site B
  4. once the user is logged in to site B, a code returns to OKTA which is successfully changed with a session
  5. BUT it seems that OKTA loses the context - and doesn’t redirect back to site A with its own code

tl;dr -
expected: siteA → OKTA → siteB → OKTA → siteA
actual: siteA → OKTA → siteB → OKTA dashboard

some more details:

from siteA, arriving to the OKTA’s page: /oauth2/v1/authorize , with the following QS params:

  • client_id
  • response_type: “code”
  • scope: “openid email profile”
  • redirect_uri: siteA’s code endpoint url
  • state

when initiating the OIDC flow from the above OKTA page to siteB, i’m calling OKTA’s endpoint: /sso/idps/{clientId}

i’ve tried forwarding the state - but it was ignored.

any idea?

2

If you just need to redirect your users through a specific Identity Provider, you can include the idp parameter in your /authorize request. That will ensure the user is routed through the target Identity Provider and then forwarded along to your application with their authorization code

3

when they get from siteA to OKTA, they can login however they choose -
i have my own custom button to initiate OIDC login via siteB that the user can click,
and if so - after completing the login in siteB, they’re redirected back to OKTA, become logged in - but [and this is the issue:] not redirected back as logged user to siteA

4

Okay, so the user is able to get into the Org, but they are not being redirected to the target application.

What does your custom button do to initiate the login? Does it just construct and make an /authorize request?

5

see in the original post:

when initiating the OIDC flow from the above OKTA page to siteB, i’m calling OKTA’s endpoint: /sso/idps/{clientId}

6

That URL will only log the user into Okta through the indicated Identity Provider, not into a target application, so users will wind up on the End User Dashboard or the Default App configured for the org,

Presuming this is an OpenID Connect integration, you application should instead be making an /authorize request to route users through Okta, their IdP, and then back to the target application (via the provided redirect_uri)