I have two apps under different subdomains app-a.example.com and app-b.example.com. I want the users logged in state to persist when navigating between these two apps.
As a user
Given I have logged in on app-a.example.com
When I navigate to app-b.example.com in the same browsing state
Then I should retain my logged in state and I should be able to retreive my access token
Initially, the user won’t have the ability to login via app-b.example.com so I wonder if I still need to setup multiple apps within the same Okta workspace / dashboard or if I should just do it all under one app (i.e. use the same clientId across both websites?)
How can I set this up with Okta? Do I need to configure a list of allowed subdomains? I can only see options for allowed callback URL’s and logout URL’s but this won’t be required since the user wont be logging in via app-b.example.com.
Ideally, calling oktaAuth.getAccessToken() on both app-a and app-b should return the access token. How can I achieve this?
Having your applications run under the same domain or not does not dictate if a user can SSO into the other unless you are doing some custom implementation. SSO depends on whether the user has an existing valid Okta session.
There is a situation where having your applications run under the same domain as your Okta Orgs custom domain URL (if one is setup) is helpful, but this has to do with browsers cross site requests settings which the Okta sessions API relies on. More on this later.
If you have 2 OIDC apps, app-a and app-b.
A user logs into app-a, they get tokens for that application and a Okta session is set for their Okta Org domain.
The user then navigates to app-b. There is no way for app-b to have access to the Okta session cookie set for their Okta Org. So the app-b can either,
/authorize into app-b. If a Okta session exists the user will be redirected back to the application without entering credentials.
use the Okta sessions API to see if a Okta session exists. If so do an /authorize to get tokens, if not carry out whatever logic appropriate.
Where the applications domain makes a difference is for browsers that don’t have 3rd party cookies enabled. In this case the sessions API can’t be used unless your applications run in the same domain as your Okta Org.
in general if you have two applications then each should have a unique application registered in Okta with it’s own client_id.
First a clarification: Your example shows two apps in example.com. Are you calling the app names subdomains? A subdomain name would be registered in DNS, an app name wouldn’t be.
Avoid sharing a single logical client IDs across physical apps, if one is compromised you have to redo everything. What you are looking for is Federated (or Web) Single Sign-on across multiple apps. It is irrelevant what domains they are in. Create a separate OIDC integration for each app, each with their own URI(s).
Whichever app the user reaches first forces the user to authenticate, and they get a session at the Okta org. A visit to any other app integrated into the same org will not require re-authentication unless the session expires or the user is logged out of the Okta org. Either use /authorize directly, or better use the Okta authorization SDK for your programming environment.
If you are authenticating against the org authorization server you can get an OAuth access token to communicate with the session API, you don’t need to worry about third-party cookies. If you want to keep the Okta session alive while the user continues to use any app, you can use the session API to keep extending the Okta session.
This is exactly the scenario for customer facing applications. It’s what is described in the Okta example code and in the Okta courses for developers too. The customer thinks they are working with one monolithic application, but in reality there are separate applications for purchasing product, managing rewards, editing the customer profile, etc. The user moves between the applications and SSO keeps the user from having to re-authenticate. All of the applications keep extending the Okta session so that if the user hangs out too long in one they don’t accidentally lose their Okta session and can smoothly move to another app. Of course if an application session expires, or the user logs out of the customer portal, then we stop extending the Okta session and we log the user out of Okta
