# Preserve the state of a nested oidc flow **URL:** \ **Category:** OAuth/OIDC\ **Created:** [March 25, 2024, 4:41pm UTC](https://devforum.okta.com/t/preserve-the-state-of-a-nested-oidc-flow/27409 "2024-03-25T16:41:20Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![baryo\_fido\_fun](https://avatars.discourse-cdn.com/v4/letter/b/0ea827/32.png) [@baryo\_fido\_fun](https://devforum.okta.com/u/baryo_fido_fun)\ **Post date:** [March 25, 2024, 4:41pm UTC](https://devforum.okta.com/t/preserve-the-state-of-a-nested-oidc-flow/27409/1 "2024-03-25T16:41:20Z")
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? ---
**Author:** ![andrea](https://sea1.discourse-cdn.com/oktadev/user_avatar/devforum.okta.com/andrea/32/2172_2.png) [@andrea](https://devforum.okta.com/u/andrea)\ **Post date:** [April 2, 2024, 3:44pm UTC](https://devforum.okta.com/t/preserve-the-state-of-a-nested-oidc-flow/27409/2 "2024-04-02T15:44:05Z")
If you just need to redirect your users through a specific Identity Provider, you can include the `idp` [parameter in your /authorize request](https://developer.okta.com/docs/reference/api/oidc/#request-parameters). That will ensure the user is routed through the target Identity Provider and _then_ forwarded along to your application with their authorization code ---
**Author:** ![baryo\_fido\_fun](https://avatars.discourse-cdn.com/v4/letter/b/0ea827/32.png) [@baryo\_fido\_fun](https://devforum.okta.com/u/baryo_fido_fun)\ **Post date:** [April 3, 2024, 7:24am UTC](https://devforum.okta.com/t/preserve-the-state-of-a-nested-oidc-flow/27409/3 "2024-04-03T07:24:45Z")
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 ---
**Author:** ![andrea](https://sea1.discourse-cdn.com/oktadev/user_avatar/devforum.okta.com/andrea/32/2172_2.png) [@andrea](https://devforum.okta.com/u/andrea)\ **Post date:** [April 3, 2024, 3:42pm UTC](https://devforum.okta.com/t/preserve-the-state-of-a-nested-oidc-flow/27409/4 "2024-04-03T15:42:47Z")
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? ---
**Author:** ![baryo\_fido\_fun](https://avatars.discourse-cdn.com/v4/letter/b/0ea827/32.png) [@baryo\_fido\_fun](https://devforum.okta.com/u/baryo_fido_fun)\ **Post date:** [April 3, 2024, 4:05pm UTC](https://devforum.okta.com/t/preserve-the-state-of-a-nested-oidc-flow/27409/5 "2024-04-03T16:05:18Z")
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} ---
**Author:** ![andrea](https://sea1.discourse-cdn.com/oktadev/user_avatar/devforum.okta.com/andrea/32/2172_2.png) [@andrea](https://devforum.okta.com/u/andrea)\ **Post date:** [April 3, 2024, 5:53pm UTC](https://devforum.okta.com/t/preserve-the-state-of-a-nested-oidc-flow/27409/6 "2024-04-03T17:53:27Z")
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) ---
**Author:** ![system](https://global.discourse-cdn.com/oktadev/original/1X/589c4c5f80de422d01f47cee7185a7fb8227835c.png) [@system](https://devforum.okta.com/u/system)\ **Post date:** [May 3, 2024, 5:54pm UTC](https://devforum.okta.com/t/preserve-the-state-of-a-nested-oidc-flow/27409/7 "2024-05-03T17:54:04Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.