I am sure I am missing something fundamental here, but if a user logs in via our okta site / login page, how do the apps under “Work” on the app/UserHome page know the user is logged in? My understanding is that when they click on a tile a token ( access token I would guess? ) is sent in the request to that page, but I’ve tried many approaches to see what comes back and there never seems to be a token.
The only option for creating these apps seems to be SPA, so you end up with a clientId that you can use in the OktaAuth({}) config. That’s also the only option that allows you to set a page URL as opposed to a login / redirect. I assumed that the page ( auth-js, more specifically ) processed the clientId and the token to figure out scope / claims, was how you could get the token… but that doesn’t seem to be the case.
Does this just rely on a cookie getting set when the user logs into our Okta page? Does that then lead back to the Third-party cookie issue and the need to have a Custom Domain to make this work?
When a user logs into Okta, a session cookie called “sid” is set on the Okta domain they logged into, for example https://org.okta.com.
When an OIDC application requests tokens for a user, it does so via a browser redirect back to the same org in an authorize request, which will look something like this: https://org.okta.com/oauth2/v1/authorize?client_id=123456789&scope=openid... and so on. When this request is made, Okta is checking to see if they have a valid ‘sid’ cookie on the Okta domain and check if the user issued that cookie is assigned the application. In either case, as long as the authorize URL is well-formed, they will be redirected back to the application via the redirect_uri specified with either tokens (implicit flow), an authorization code (authorization code flow with or without PKCE auth).
Because the application does a browser redirect in this scenario, you don’t have to worry about third party cookies: if the authorize request gets made on the Okta domain where the cookies were created, they are first party and should work whether or not the browser is blocking third party cookies.
However, our SDKs use iframes behind the scenes to prevent some redirects from happening to help improve the user experience for SPAs. You can find the list of functions from the Auth JS library that make CORS requests to Okta that require being able to reach the session cookie to succeed here. If you are using any of these functions or their related API endpoints (such as /sessions/me), then yes, you will want to configure a custom domain for your Okta tenant AND host your application on the same domain so that these CORS requests succeed in browsers that block 3rd party cookies.
You can find more information about how this may affect you in this article.
Thanks for the reply. I only seem to be able to add a login redirect for an OIDC app, not a link to the actual page I want to log the user into. Does this mean I need to create identical-looking log in pages for every app, just so that they can redirect to the specific logged-in page I want to grant the user access to? And every separate log-in page would have the clientId in the auth config relating to each app? I have a logged in user, with an app tile representing an OIDC app, but if I click on that app tile there is still no way that page can tell if the user is logged in. There are no parameters in the query string ( like a token, or even a clientId ), and because the sid cookie is on the xxxx.okta.com domain, obviously the page will never see it. Is it impossible to test this in a local dev environment?
like I mentioned in the other post, yes, you can rely on the presense of the Okta sessions, but you would need to have a custom domain set up so that the cookies are first party and accessible in browsers blocking third party cookies.
If your use case is that user access page x, which requires them to be authenticated, and that Okta redirects back to the redirect_uri provided instead of page x, you will need to decide on a way to track the page the user was on before they were prompted to authenticate so that you can send them back to this page FROM the redirect/callback route.
This is what our front-end SDKs do for you via the originalUri, and you may wish to implement something similar so that this original page is tracked somewhere (say, in a cookie/local storage) and then fetched once the user has tokens so they can access the desired page.
Thanks for the reply. We ended up making seperate login pages for each and adding that to Okta Application config for each SPA. We have a custom domain, but we couldn’t figure out how to make any useful API calls. Since we only wanted group membership, we just ended up passing those back in the claim. The final missing link was that the JWT is POSTed from the tile you click on in the Okta home tab. Once we decoded / validated that on the client side, it all worked.
