No okta-token-storage nor okta-original-uri-storage when user is signed in

I don’t usueally work win Angular apps but, I have to maintain one so this is my question.
I have an applicacion that uses Okta to sign in users.
I can sign in a user on my local environment. I can also sign in the same user with the okta-sample-login app downloaded from GitHub - okta/samples-js-angular: samples-js-angular

For both apps when I check the browser → Developer tools/Application/Storage/Local Storage I can see:

  • okta-original-uri-storage
  • okta-cache-storage
  • okta-shared-transaction-storage
  • okta-token-storage with accessToken and idToken

As the applications were working on my local environment through http (Windows + Visual Code) I deployed my application on a Linux server + Apache Tomcat through https.
For both environments I’m using the same client-id and Issuer

When I try to sign in on the Linux installation with a valid url (not localhost:port nor servername:port) I don’t get any error but, on my browser → Developer tools/Application/Storage/Local Storage I can only see:

  • okta-cache-storage
  • okta-shared-transaction-storage

Due to that, I decided to deploy the okta-sample-login on the same Linux server.
I built the app running ng build --prod --base-href yoursubfolder where yoursubfolder is the one I’m going to deploy the app on the server
For more info about this: angular - Failed to load module script - Stack Overflow

And for my surprise, I get the same result as in my application.

The user is signed in on Okta but I can not access to okta-token-storage so, I cannot check if the user is Authenticated or not with this.isAuthenticated = await this.oktaAuth.isAuthenticated();

I checked the next link which seems to be similar

The okta libraries I’m using on my application are:

  • @okta/okta-angular”: “^4.1.0”,
  • @okta/okta-auth-js”: “^5.5.0”,

The Okta Portal configuration is done by another team
I tested both applications on Edge and Chrome with the same result.

This is a piece of code I’m checking this issue with
async ngOnInit() {
const tokenManager: TokenManager = this.oktaAuth.tokenManager;
const accessToken: AccessToken = await tokenManager.get(‘accessToken’) as AccessToken;
const idToken: IDToken = await tokenManager.get(‘idToken’) as IDToken;

    this.isAuthenticated = await this.oktaAuth.isAuthenticated();
    if (this.isAuthenticated) {
        console.log("User is authenticated")
        .then(function (token) {
            if (token) {
                console.log("idToken found")
            } else {
                console.log("idToken not found")
        .catch(function(err) {
            console.log("idToken error")
    } else {
        console.log("User is not authenticated")

Anyone knows why okta-shared-transaction-storage and okta-token-storage are not created in the Local Storage when I use the Linux application?

I’ll appreciate any help

Thanks & Regards
Javier Martín

Is it just that you can’t find the tokens in local storage, or are they also not present within the tokenManager?

We have some fallback logic around where the tokens are stored (doc’d in the AuthJS readme). Do you also not see them in the session or cookie storage?


They are not stored in any repository nor session nor cookies.
On sessionStorge I can see referrerPath and okta-transaction-storage.
On Cookies storage I can see okta-oauth-state, okta-oauth-nonce and okta-oauth-redirect-params.

I made yesterday a new test. This time, instead of connecting to my company Okta portal I connected the app to a Developer Okta portal. On this test I only added callback and logout URIs and also trusted origins.

I’ve got the same results than in my previous test. Looking to System Logs in the Okta portal, I can see some differences depending on if I connected from localhost or from the https url from our integration server.

In the next table (copied from a Excel sheet) there are the different scenarios and logs I’d got

sign in from localhost INFO OAuth2 id token is granted
INFO user.authentication.sso User single sign on to app
INFO user.session.start User login to Okta
INFO OAuth2 authorization code request
INFO OAuth2 access token is granted
INFO policy.evaluate_sign_on Evaluation of sign-on policy
INFO user.authentication.verify Verify user identity
logout from localhost INFO user.session.end User logout from Okta
INFO OAuth2 token revocation request
sign in from integration server(https) INFO OAuth2 authorization code request
INFO policy.evaluate_sign_on Evaluation of sign-on policy
INFO user.authentication.verify Verify user identity
INFO OAuth2 authorization code request
INFO user.session.start User login to Okta
logout from integration server (https) INFO user.session.end User logout from Okta


Kind of looks like your server isn’t making the /token call to Okta to exchange the authorization code for tokens, which would explain why they’re not stored anywhere.

Is your app throwing any sort of errors when the user logs in?

There are no errors.
All requests I can see on Browser’s Network tab end with a httpstatus=200

@andrea could be a clue that we are using a load balancer between the https url and the http url in which the app is deployed?

Potentially. A related thought: the app is hosted on http? And you’re using PKCE flow? You need to use HTTPS with WebCrypto. Might be worth quickly testing the response of isPKCESupported to see if that could be part of the problem.

The app is hosted on https and PKCE is supported.

Following the requests sent to the server, /token, /keys and /userinfo are not sent to server when the app is running on https, as you mention on a message before

I know you said there were not errors on the network tab, so all API calls that are getting made are succeeding. Is nothing thrown in browser console either? You may want to ensure you have “Preserve log” enabled in your browser to ensure that you’re not losing any of the logs when the application/Okta redirects.

Dear fcojavierm,
Did you found the solution for the Sign-in problem? I also have the same problem. In the comments, I did not see that you was successful.