Still struggling to understand Id Token vs Access Token in OIDC / OAUTH2.0

Question

I've ready many stackoverflow answer, watched youtube videos and read many articles, and I still can't completely understand why we need two tokens. Here are my assumptions, please tell me where I am going wrong:

Access Token:

1. Result of some oauth flow, where an application requests for access to a resource on my behalf.

2. Contains information about what access has been granted

3. Can be any string format (Not necessarily a JWT), it's only important that the intended recipient can understand it.

4. Could potentially contain information about the ID of the person who granted the access (Me!)

5. Must be kept secret!

ID Token:

1. Result of oidc flow(extension on top of oauth flow)

2. Contains information about the user (Me!) who authenticated, for example their username.

3. Is intended as nothing more than a standardized way to distribute information about the user. No actions are actually performed using the Id Token

4. Can be leaked without danger.

Access token "flow":

User X wants Service A to access Service B on its behalf

User X is directed to Service B and authenticates

Service B sends an access token to Service A

Service A can now access Service B on behalf of User X according to the access rights contained within the token.

Id token "flow":

User X signs up for Service A using Login to Service B.

User X is directed to Service B and authenticates.

Service B sends Id token to Service A.

Service A can now display a personalized welcome message, "Hello User X"

Is any of this wrong or am I missing something?

Am I wrong in thinking that potentially User X could Authenticate against Service B, and grant access rights (access token) to some UserInformationAPI of Service B to Service A, which could then use that token to query Service B to read user information, and that this is in essence the same result as simply passing a standardized Id token to Service A directly?

Answer 1

ID Token and Access Token will bring the same result, if you limit discussion to getting user information only. In the case of ID Token, you can find user information in the payload part of the ID Token. In the case of Access Token, you can get user information by presenting the Access Token at the userinfo endopoint.

However, if you want to do other things than getting user information, in other words, if you want to access other Web APIs than the userinfo endpoint, you need an Access Token.

A simple difference between ID Token and Access Token is that ID Token is interpreted by Client while Access Token is interpreted by Resource Server.

It's worth reading "Identity Federation by OpenID Connect". The Step 14 in the article says as follows:

Step 14

The payload part of the ID token includes information about the user. If the information is not enough, the userinfo endpoint (OpenID Connect Core 1.0 Section 5.3 UserInfo Endpoint) can be utilized. Note that the userinfo endpoint requires an access token which covers at least the openid scope.

Answer 2

ID tokens are just proof of the authentication event. If required, a web or mobile client can see how and when the user authenticated. In most use cases though, the ID token is ignored by application code. The ID token should never be sent from the client.

When a web app uses its own cookie layer, it may initiate a session after receiving tokens and verifying the ID token.

Access tokens are the important ones. These are used to protect your data. In OAuth, a client (or User X in your question) gets one from an Authorization Server, once user authentication is complete. The token does not get returned from Service B.

Access tokens can be forwarded between related services (in the same organization). The scope, claims and audience within the access token payload are mechanisms that can be used to enforce access control. How you design this is up to you.