I have one application built in Angular with a custom login screen that uses Okta’s APIs and an OIDC flow. I have another application built in React which is really just some pages in the main application. Meaning, from the user perspective they are remaining within the same portal. Some pages of the portal are built in React and are therefore constructed as a separate app. Both the React and Angular apps share the same backend API application. They are also both hosted on the same domain/servers (although right now I am running locally and they are on different ports.)
Once a user is logged into the main Angular application, I need them to be able to bridge into the React app seamlessly when they click a link, without seeing a login screen or prompt. Additionally, if they try to access the React app and don’t have a valid session, they must be directed to the custom login page for the Angular app.
I am using the official okta libraries for Angular and React. Please note that all applications here are existing applications that are being migrated to an Okta login, not new applications.
I already tried getWithoutPrompt, but it relies on third-party cookies and iframes having permissions on sessionStorage, which are now disallowed by default in Chrome and many other browsers.
Can anyone suggest an approach for authenticating seamlessly into the React application? That would be much appreciated.
If you use the redirect model to have users log into the first application (users will need to login on the Okta hosted login page), users will receive an Okta session set on your Okta org’s domain (custom or default, depending on your environment). Then, when the second application makes its own /authorize redirect to log users in, the user will be briefly sent back to the Okta domain to login.
As long as the user’s session from the first login is still active (e.g. it hasn’t expired) and the second application does not require any additional factor authentication or re-authentication (based on its assigned Authentication Policy), then the user will be automatically logged into the second application (i.e. immediately redirected back to the redirect_uri) without being prompted for auth again.
Why do the users need to login on the Okta hosted login page? Is there a way to make this work while using our custom login page hosted in Angular? We cannot use an Okta hosted login page at this time.
This makes the requirement much clearer. Since you need to stick with your custom login UI, you are correct that the standard “redirect to Okta” model might not fit your needs.
To answer your question on why the previous response mentioned the Okta Hosted Login: Two standalone apps relying on Okta SSO for authentication separately, requires a global session cookie on the Okta domain which allows a second standalone app to log in “silently” without a prompt.
However, you can bypass this entirely.
Since your React app is conceptually part of the main portal and hosted on the same domain, you could avoid treating it as a standalone app. Instead, you can use a Centralized Shell pattern. In this model, your Angular app acts as the “Host” (or Shell) that manages the user’s identity, while the React app acts as a “Consumer” that simply uses the existing session.
Here is how you can architect this to be seamless:
Keep the Auth Logic in Angular: Let the Angular app handle the actual login and token retrieval.
Pass the Token to React:
If you are using a Micro-Frontend pattern (e.g., rendering React inside an Angular component), explicitly pass the access token as a prop to the React root.
If the apps are just sharing the same domain/subdomain, you can store the token in localStorage (or a secure cookie) that both apps can access.
Configure React as “Passive”: Update the React app to look for this existing token on initialization.
If the token exists → Initialize the API client and render the view.
If the token is missing → Redirect the user back to the Angular custom login route.
This approach lets the “Host” app manage authentication while the “Remote” app simply consumes the session, completely avoiding the need for an Okta-hosted login page or third-party cookies.
Can you point me to any documentation that discusses the Centralized Shell pattern?
In addition, please note that I am not using a micro-frontend pattern, but rather a full redirect to the React application which is hosted on the same domain.
I also need my React application to be able to retrieve new access tokens for every resource request (I understand that is the appropriate way of handling tokens, and is what we are doing in the Angular application), and to get a new refresh token before the session times out.
Is this practical with the Centralized Shell pattern that you have outlined? How would I go about that?
We don’t have specific documentation for this exact Centralized Shell pattern, as it is a custom implementation rather than a standard Okta pattern. We do have a blog about creating micro front end and sharing state using module federation - How to Build Micro Frontends Using Module Federation in Angular | Okta Developer
As far as my recommendation for non MFEs, the way you can share the auth state is by using a common storage manager between the two apps. However you might have to tweak a little bit to make sure you load the angular login page when auth is needed (as described in point 3 of my earlier response).