Can't add or get idToken when using cookie storage for token manager

[johanerikssontrustly]

Started updating from 2.x.x to 4.x.x and immediately ran into some problems with storing the idToken returned from the redirect callback while using cookie storage.

Given the following code

async handleRedirectCallback() {
    const { tokens } = await this.authClient.token.parseFromUrl();
    const { accessToken, idToken } = tokens;

    console.log('Parsed ID Token', idToken);
    console.log('Parsed Access Token', accessToken);

    if (accessToken) {
      this.authClient.tokenManager.add('accessToken', accessToken);
    }

    if (idToken) {
      this.authClient.tokenManager.add('idToken', idToken);
    }

    const storedIdToken = await this.authClient.tokenManager.get('idToken');
    const storedAccessToken = await this.authClient.tokenManager.get(
      'accessToken'
    );

    console.log('Stored ID Token', storedIdToken);
    console.log('Stored Access Token', storedAccessToken);

    const pathName = localStorage.getItem(RETURN_PATH_KEY);
    localStorage.removeItem(RETURN_PATH_KEY);

    return pathName;
  }

I get this output

Parsed ID Token [Object]
Parsed Access Token [Object]

Stored ID Token undefined
Stored Access Token [Object]

Both the accessToken and idToken are successfully retrieved from parseFromUrl(). After that, I'm able to retrieve the accessToken as expected, but the idToken is nowhere to be seen.

I've tested this in both Chrome and Firefox with third-party cookies enabled and disabled, and none of it works.

• The problem persists when downgrading to 3.x.x
• Switching to localStorage fixes the problem.

[shuowu]

@johanerikssontrustly The issue is caused by cookie's size limitation, it has been fixed since v3.1.4 (https://github.com/okta/okta-auth-js/blob/master/CHANGELOG.md#314).

Also, token.value is a redundant field, feel free to remove it to reduce the token's size.

[johanerikssontrustly]

@johanerikssontrustly The issue is caused by cookie's size limitation, it has been fixed since v3.1.4 (https://github.com/okta/okta-auth-js/blob/master/CHANGELOG.md#314).

Also, token.value is a redundant field, feel free to remove it to reduce the token's size.

I still encountered the issue with v4.0.2. However, I did resolve it by removing the value property before storing tokens.

[aarongranick-okta]

@johanerikssontrustly Thanks for the feedback. We will remove token.value in an upcoming version. Internal ref: OKTA-338251

[kculmback]

We ran into a similar issue, but with refresh tokens. We cannot store accessToken, idToken, and refreshToken in the same cookie (even deleting value from each one). So we had to do some funky logic to split the three tokens into separate cookies so that we can store all of them.

[darkowic]

Still doesn't work in 4.7.2. I'm testing auth after upgrade from v4 and when using cookie storage the returned state is:

It's a bit problematic. As a workaround, I need to write transformAuthState logic to support this:

const transformAuthState: OktaAuthOptions['transformAuthState'] = async (
    oktaAuth,
    authState
) => {
    // cookie size limitation causes issue with storing IDToken
    // https://github.com/okta/okta-auth-js/issues/507
    // As workaround require only accessToken to be available to mark user as authenticated
    if (
        oktaAuth.options.tokenManager?.storage === 'cookie' ||
        // Even though we are setting different storage than cookie
        // we still can fallback to cookie if other storages are not available
        (authState.accessToken && !authState.idToken)
    ) {
        return {
            ...authState,
            isAuthenticated: !!authState.accessToken,
        };
    }
    return authState;
};

[aarongranick-okta]

@darkowic Do you know why the idToken is so large? Does it include a lot of custom scopes / data? Also I'm curious why you need to use cookie storage. Are you trying to share the tokens with a backend app?

[darkowic]

We are developing a platform for other teams which allows using different storages and in our test env we are using cookie storage because of probably legacy requirements (I need to investigate it).

About the IDToken: we have a custom (I believe it is custom) claim groups which for my token is a list of 43 10-20 characters strings. And there are different data too. This may be the reason why it is so big but I can not do much about it.

I will investigate if we can avoid using cookie storage.

[shuowu]

@darkowic Probably you can try only add base claims to the idToken, then get the full user info from /userinfo endpoint (if using cookie as storage is mandatory).

Referenece: https://developer.okta.com/docs/reference/api/oidc/#claims-in-the-payload-section https://developer.okta.com/docs/reference/api/oidc/#userinfo