Can different trusted applications get different access tokens within the same user session?

We have a CIAM use-case where we are trying to allow customer access to all of our customer-facing applications using only a single userId. These apps are relatively independent and have their own scopes/claims. Rather than create a single giant accessToken with scopes/claims for every app they could possibly access, we’d like to have the user authenticate just once (i.e., SSO), but have each app be able to get its own access token (with its own scopes/claims).

We are using a custom login application and OIDC Authorization Code Flow. The session token created by /authn can be used by the first app to pass to /authorize to get the code it can exchange for an access token. But session tokens are one-time use/short-lived. Is there something in the session_cookie that could be used by other (trusted) apps to initiate their own authorization code flow?

Or some other way to meet the requirement to get multiple app-specific access tokens for the user session?

Hi @steve.melville

The best solution would be to open a session in Okta client-side through a request to /api/v1/authn to retrieve the sessionToken and a first redirect to /authorize containing sessionToken as query parameter.

Once this is done and user accesses other applications on your end, you can check /api/v1/sessions/me to see if there is an active session in Okta and, if yes, simply redirect to the authorization endpoint, otherwise display the sign-in page.

Hi Dragos,

Wouldnt you recommend a seperate authorization server per application to accomplish this?

Hi @Govner

This depends on the current architecture.

A single authorization server is easy to deploy and the claims can be retrieved based on specific scopes requested. The custom claims and audience inside JWT tokens can be easily modified using the Token Inline Hook feature.

Multiple authorization servers take a bit more time to deploy, however they give more flexibility over the claims that can be requested.

Thanks, @dragos and @Govner. My actual goal was a back-channel method for doing this. But, as of now, I’ve discovered no way to do this back-channel. So the re-direct to /authorize seems the way to go. The call to /api/v1/sessions/me would allow me to check for a session before initiating the re-direct. Although, I think just attempting the re-direct may also work, right? If there is no session, I would just get an error on the redirectURI, wouldn’t I?

Hi @steve.melville

If there is no session in Okta when accessing the authorization endpoint, the user will be prompted to log in. Once he authenticates, he will be redirected back to the respective redirectUri.

Hi @dragos. Right. So the call to /api/v1/sessions/me is unnecessary. I’m just intending to re-direct to the /authorize end-point (with prompt=none since we have our own login app) and let it tell me if the user has a session (in which case it will send authorization code to the redirectURI) or not (in which case it will send an error to the redirectURI).