Other OIDC identity provider is not being called after login to first idp

[tauinger]

Hello everybody,

I have two identity providers (Apple and Google) configured.

After I could obtain an auth code using one of them (starting flow via https://xyz.oktapreview.com/oauth2/v1/authorize?idp=12345…) I automatically get a new auth code when opening the corresponding URL for the other idp (e.g. https://xyz.oktapreview.com/oauth2/v1/authorize?idp=7890…). This auth code contains all user details of the first idp – but I started the auth flow for the second idp.

Why is that? How do I disable that?

I could observe that closing the session has no effect on this behaviour. However, deleting all browser data did have an effect, i.e. when opening the 2nd url I then actually see the login page instead of just being redirected back instantly.

[andrea]

If you are already logged into Okta on your browser, the second idp provided will be ignored and tokens will returned for the idp/user that was already logged in.

If you are just testing this yourself, you can delete the ‘sid’ cookie that is set on your Okta domain, which is what the authorize call uses to check if a user is already logged in on that browser.

[tauinger]

Thanks a lot for your reply.

Can I disable that behaviour in Okta? Since we are calling the Okta authorize URL from a native app via a web-view I don’t think we can delete cookies…

[andrea]

Not that I know of, no. You could look to try deleting the cookie (ending the Okta session) via a CORS request before making the second authorize call (or any authorize call, if that’s the desired set up):

[tauinger]

Ok.

Is there any kind of logout endpoint that would destroy the session (or whatever is identified with the sid parameter)?

[andrea]

Yup, OIDC has a logout endpoint, but you need to redirect to it and pass the id token issued to the user with the session in that browser. It will achieve the same thing, removing that Okta ‘sid’ cookie.