Why does this library recommend to use 'id' on the backend?

[MartinDawson]

tokenUse: The type of token to be used. It is recommended to use "id" instead of "access" token.

AFAIK, id is not correct for verifying. You should use access tokens as it's more secure.

https://stackoverflow.com/a/75186361

Also, a bit of a side issue, id tokens work like so:

options.headers['Authorization'] = 'Bearer ${token.idToken.raw}';

CognitoAuthModule.registerAsync({
      imports: [ConfigModule],
      useFactory: async (configService: ConfigService) => ({
        jwtVerifier: {
          userPoolId: configService.get('COGNITO_USER_POOL_ID') as string,
          clientId: configService.get('COGNITO_CLIENT_ID'),
          tokenUse: 'id',
        },
      }),
      inject: [ConfigService],
    }),

But when I try to use accessTokens I just get 401 errors...

options.headers['Authorization'] = 'Bearer ${token.accessToken.raw}';

 CognitoAuthModule.registerAsync({
      imports: [ConfigModule],
      useFactory: async (configService: ConfigService) => ({
        jwtVerifier: {
          userPoolId: configService.get('COGNITO_USER_POOL_ID') as string,
          clientId: configService.get('COGNITO_CLIENT_ID'),
          tokenUse: 'access',
        },
      }),
      inject: [ConfigService],
    }),

Not sure why that is as that should work.

[Lokicoule]

First, it’s important to note that AWS Cognito and Auth0 are different, and the behavior of access and ID tokens isn’t identical. While the roles of access and ID tokens are now clearly defined under OAuth 2.0 and OpenID Connect (OIDC) standards—particularly with providers like Auth0—AWS Cognito’s documentation from a few years ago provided different guidance. At that time, using the ID token was recommended in certain scenarios, and it aligned with my use case. However, I agree that it was a mistake to suggest that using the ID token is the recommended approach today.

Also, this is the second time someone has mentioned issues with the access token not working. It’s possible that a dependency upgrade could have broken it, so I’ll investigate that further. Thanks for bringing it to my attention.

[MartinDawson]

got it, thanks