Difference between session.setCookieAndRedirect() and signInWithRedirect()

I’m wondering what is the difference between oktaAuth.session.setCookieAndRedirect() and oktaAuth.signInWithRedirect() ?

if oktaAuth.session.setCookieAndRedirect() set a cookie, what is the difference between this cookie and the sid (session token) set by signInWithRedirect() ?


signInWithRedirect is used to kick of an /authorize call to log users into an OIDC application, while setCookieAndRedirect is intended to be used for non-OIDC SSO integrations (such as SAML), that need an Okta session created and then redirect to the SP or another site.

This method will NOT initiate an /authorize request, which is why it is not recommended to use it if you are trying to log users into an OIDC application.

Thank you @andrea for your reply.
I think that I will use setCookieAndRedirect since it doesn’t store accessToken and idToken in the local storage of the browser.

Howver, I’m wondering how to keep the session connected even if the client closes the browser?
I’m using the okta auth sdk, does it return a refresh token after an authentication success ?


If you’re trying to maintain the Okta session when the browser is closed, you will want to look into using Persistent Cookies (you must do an API call to update sign-on policies to have this enabled). See documentation here.

And, if you are requesting the offline_access scope AND your application has refresh tokens enabled as an allowed grant type, yes, you can get refresh tokens returned to your tokenManager. For SPA’s you should review the following guide: Refresh token rotation | Okta Developer

Thanks again @andrea for your reply.

Yes I have a SPA, and I don’t know how to retrieve a session cookie to set it in the browser. And if I do so, how to use this cookie (sid) to keep end user signed in?

Any other solution is welcome.


the session cookie is created on the okta domain. The only interaction your app will have with it is to help set it (using the sessionToken returned from the /authn endpoint OR in the course of an OIDC login flow) OR to use to facilitate SSO (either as a third party cookie when your domain checks the okta domain for its presence, or via redirect to Okta to confirm the cookie is there and the session is still valid).

If you care about the cookie to keep users logged in, like I said, you want to look into updating the Org Sign On Policy to make these cookies persistent so they stick around if/when the browser is closed.

For OIDC apps however, we recommend using refresh tokens to keep users signed in instead, so I would really recommend looking into how they work (see the guide I linked to above).

What I’m looking for is to keep user signed in (when he checks keep me signed in check box) even if he closes the browser (keep a okta session alive).

Could you give me more details about Org Sign On Policy to make these cookies persisten please? I had a look to authentication policies but I only found Session expires after option which will be removed when I close the browser.

Thanks again for your help.

I also want to get and reuse refresh_tokens, but I don’t know how to do it.
I didn’t find anything about it in the okta auth sdk.