SSO from SAML to OIDC App which has custom login page

Step 1: Okta Login Page (okta initiated flow)
Step 2 : Okta does a SAMl assertion to Application 1 (this is our portal app where we have links for other applications which also uses okta for auth)
Step 3 : From Application 1 I open the protected url of Application 2(SPA OIDC PKCE Okta Login Page) in next tab. The Okta SDK (angular or react) initiates the authorize flow and but instead of showing Okta login page user is redirected to callback url with Auth Code. I think here Okta used the session cookie
Step 4 : From Application 1 I open the protected url of Application 3(SPA OIDC PKCE Custom Login Page) in next tab. The Okta SDK takes user to Custom login page. I was expecting Application 2 to initiate authorize flow using cookie.

I think it is because of the domain difference.
Question:

  1. How can we SSO into such custom login page apps (okta widget inside app) without asking for credentials.
  2. Is my Step 3 flow correct ? Or is there a better way to do this ?

As long as the user has an Okta session in the browser AND your browser is not blocking 3rd party cookies, you can, in the widget, use the underlying Auth JS library to detect this session using session.exists().

If you detect that the user already has an Okta session (aka, the Okta session cookie ‘sid’ set on the Okta domain you are using), you can immediately request tokens for the user from your OIDC application either using the getWithoutPrompt method (also 3rd party cookie dependent) or by redirecting to the authorize URL (which will not run into that 3rd part cookie issue).

I don’t see an issue with Step 3, but I’m also having trouble visualizing your application. Sounds like the users access the SAML app first, which can then launch the OIDC app? For OIDC apps, the app itself should be the one initializing the authorize call (SP-initiated login), so you will need to redirect the user to the OIDC app and let the OIDC app handle the PKCE flow, whether that’s to a specific protected route or to the landing/login page.

Details about the 3rd party cookie limitation I mentioned found here: Okta Help Center (Lightning)

1 Like

Thanks .

Application 1 which supports only SAML acts like a portal dashboard for all other OIDC apps. Step 3 works fine since Application 2 initiates authorize flow and Okta Hosted Login Widget recognizes the cookies and sends Auth code without credential prompt.

But when we open Application 3 , it has App hosted Okta Widget so it is looking only for Id and access token in local storage and sends user to login page. We using Okta React SDK for this.

Then yeah, sounds like App 3 needs to check for the presence of an Okta session (cookie) and to either try to request tokens via getWithoutPrompt (happens in an iFrame so there is not visible redirect for the user, but 3rd party cookies must not be blocked) or by redirecting to Okta again instead of having them login through an embedded sign in page.

1 Like

Hey @andrea I’m working through something similar and you may have helped me get a breakthrough. If the app is using OpenID with a long lived refresh token, would the Okta session cookie have expired or is it refreshed when you request another access token?

The Okta session cookie/Okta session lifetime won’t be affected when you refresh tokens via a refresh token. The Okta session will expire if its not refreshed itself.

Hey @andrea So I’m assuming you cannot refresh a session once it’s expired even with a valid refresh token?

Our scenario is: we have a mobile app with long refresh token lifetimes (1 month). When a user clicks a link in the app, we want to be able to open a webpage/single page application and single sign them in so the SPA knows who they are and personalises and prefills the page with the user’s information. The mobile app and the SPA are different Okta applications. Okta session is still the default 2 hours.

It is most likely by the time the user clicks the link that the original session will have expired.

That’s correct. Once the Okta session has expired, the only way to get this session back is to have the user re-authenticate to Okta.

It might be tricky to have the SPA and mobile app connected unless you’re linking the two “sessions” together on your side somehow (maybe via a central server that both apps check in with?)