How do apps know about users logged in via okta UserHome?

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? :open_mouth: