Okta invoking callback URL with different "credentials" header after 2FA flow?

Questions
1

Hi, I’m integrating a standalone web application with a customer’s Okta instance, using the OIDC authorization code flow, implemented server-side.

I find that when a user is not currently logged-in to Okta, the inital redirect from my website to <customer>.okta.com/oauth2/v1/authorize/ takes them through their login, then prompts for 2FA, as expected, and then redirects to my callbackURL (<mydomain>/auth/callback?code=<code>&state=<state>) with "credentials": "omit" in the header.

When a user is currently logged-in to Okta, the initial redirect from my website to <customer>.okta.com/oauth2/v1/authorize/ authenticates them without user input, and then redirects to my callbackURL (<mydomain>/auth/callback?code=<code>&state=<state>) with "credentials": "include" in the header.

Since I rely on cookie-based sessions, I’m unable to log the user in when the "credentials": "omit" header is present.

Is this difference expected? Should my application be handling these callbacks differently?

Thanks so much.

2

why would you need credentials parameter. I might be wrong, but it seems, it’s not a part of OIDC flow you should look at: code, state and nonce would probably be the only ones you need to take care of to comply with OIDC flow. Or am I missing something?

3

Thanks for the response phi1ipp. As you probably guessed, this turned out to be an issue on my end – I’ll describe the fix in case it’s useful to anybody else debugging.

I misinterpreted the credentials header as being part of the request from Okta. Actually, it was coming from my browser. The fact that credentials was omit in the fetch request in the first flow, versus include in the second flow, reflected the fact that I was using a session cookie configured with SameSite=strict, which prevents the browser from sending a cookie after a redirect from an external website. The fix was to configure my session cookie with SameSite=lax.

A couple references: