ID tokens vs Access Tokens
Id tokens vs Access tokens in OAuth

ID tokens vs Access Tokens

Developers often confuse ID and Access Tokens in OAuth. They can both be encoded as JWT, but the content and purpose are also different.

An ID token contains the identity information about the authenticated users, and it is intended to be consumed by the front-end application.

On the other hand, an access token represents a ticket with permission to consume an API.

The ID token and the access token are negotiated with an Authorization Server using OAuth 2.0, but the profile for getting each one is different.

An ID token is negotiated with Open ID connect when the scope is set to idtoken. Additional information can be requested to be added to that token when the scope is also set to profile and email. When the authorization server receives those scopes, and the user consents to share their identity with the front-end application, it issues an id token containing attributes or claims representing the user identity. Those claims are part of the OIDC specification and usually include,

  • Name
  • Nick Name
  • Picture
  • Email
  • Given Name
  • Family Name
  • Email_Verified

The audience set for this token is the front-end application, and this part is significant as it should only be consumed by this application and not an API.

Optionally, this ID token can also contain roles if you use the RBAC model to drive authorization decisions on the UX.

On the other hand, an access token does not contain any information about the user's identity. The scope passed by the front end on the authorization request defines the intended audience for the access token or the API this token provides access for. The token can be reused to consume other Web APIs by having that audience attribute.

Also, this access token does not contain any information about the user identity, but it could potentially include user roles if the API implements a RBAC model.

As an optimization, ID and Access token can be negotiated in a single request to the Authorization Server. When that's the case, the front end includes idtoken + api as part of the scope of the authorization request. The authorization server will return an ID token and an access token for that API in a single shot. The illustration shows that the front end used OpenID Connect + OAuth 2.0 PCKE to get the ID and access tokens.

For example, a react application consumes a backend web API for a CRM. That API was previously registered in the authorization server with the scope "api://crm". The react app will send an authorization request to the authorization server containing the following scope "idtoken api://crm". That will tell the authorization server that the application wants to authenticate the user and also asks for authorization to consume the CRM API on behalf of the same user. If the user approves that request, the authorization server will return a code that the app can use later to redeem the ID token and the access token for the CRM API.

Phani Katakam

Senior Enterprise Architect - Looking at the forests!, Also CEO of my farm!

9 个月

Does ID Token has expiry? should have it, as its token :) ... managing these expiry of these tokens could be cumbersome...? One Token should have authenticated, authorization should be able to built on the user context... instead of token.. means authorization of roles, policies are only valid until the authentication token is valid...

回复
HOUDA LAMRINI

Etudiante en Master Architecture des Réseaux et Cybersecurité

9 个月

thank you!

回复

要查看或添加评论,请登录

Pablo Cibraro的更多文章

社区洞察

其他会员也浏览了