angular-oauth2-oidc - Read user claims

Question

I'm using angular-oauth2-oidc's Code Flow in an Angular application. It's working all good, however I cannot read the user claims.

I tried using this.oAuthService.getIdToken(), this.oAuthService.getAccessToken(), this.oauthService.getUserInfo() but I don't seem to get any valid JWT that can be decoded using regular methods.

In my backend API (.NET Core) I use the access_token to query the TokenIntrospection endpoint and I can see all the claims properly.

Relevant info:

export const oAuthConfig: AuthConfig = {
  issuer: environment.oauth.issuer,
  // URL of the SPA to be redirected to after login
  redirectUri: environment.oauth.redirectUri,
  clientId: environment.oauth.clientId,
  dummyClientSecret: environment.oauth.clientSecret,
  responseType: 'code',
  scope: 'openid profile email',
  showDebugInformation: true,
  oidc: true,
  requireHttps: false,
};

async login() {
  await this.oAuthService.loadDiscoveryDocumentAndTryLogin();
  await this.oAuthService.initCodeFlow();

  this.router.navigate(['/']);
}

Any suggestions? Thanks for the help.

Answer 1

There is a getIdentityClaims method that will give you id_token claims as an object. First though you need to check the HTTP requests to verify that an id_token is actually being returned, and that it contains the claims you expect.

CLAIMS ISSUING TO TOKENS

In an Authorization Server you can specify where claims are issued to and it is very standard to issue different claims to the two tokens:

• In your case an ID token is for use by a UI client and may contain details such as a name for display
• An access token is issued for use by an API client and might contain a role or user id used for authorization.

To better understand this concept, see the Claims Mapper concept used by the Curity Identity Server.

I suspect in your case the system is not configured to (or does not support) issuing some claims to the id token.

MY PREFERENCE

I actually think you are on the right track with your access token handling. Another way for a UI to get user info is to send the access token to its API, at a path such as /api/userinfo/current, and the API can then return a JSON object containing:

• Claims from the access token
• Any other domain specific data that may be useful to the UI

This design has the following benefits:

• Extensibility: it is easy to add extra data to the API payload, which may have nothing to do with OAuth
• Privacy: adding too much user data to an id_token is often not recommended, since it is then available in a viewable JWT which lasts for an entire user session