As promised, I'll cover tokens a bit more in-depth particularly on this post, as I try to keep them as more as dry/simple as possible to make sure they're effective, so you're kind eating power food for each one of them :D

Quick recap ( some words that summarise previous content ).

1 - Authorization
2 - Authentication
3 - Client Registering
4 - Redirecting

Previously we started introducing something around tokens, we saw that tokens can carry or not user information.

That's why we have denominated two types for them:
1 - Opaque
2 - Structured

The opaque token doesn't carry any user information or role access info, on the other hand, the structured token is usually forged using a secret key and provided back by the Authorization server, therefore this token is usually also a string, but a string in which can only be parsed by those who have the secret key to retrieve user information and access roles or anything else you'd like to put on the token.

PS: It is not recommended to put more info than necessary as the token travels a lot, so it is not recommended bit-wise.

That means:

1 - Only who have the key can parse the token
2 - Resource servers should have the key in their secrets to parse the token.

With that being said the access token is now obtained, now there's another dev decision to make: "Do we need get MORE user info or not"?

Although a structured token can carry user data, it is recommended to keep it as clean as possible, a common pattern of JWT token is:

{
  "iss": "https://auth.example.com",
  "sub": "1234567890",
  "aud": "https://api.example.com",
  "iat": 1693257600,
  "exp": 1693261200,
  "scope": "read write",
  "email": "user@example.com",
  "roles": ["admin", "user"]
}

• User ID (sub): A unique identifier for the user.
• Issuer (iss): Identifies the issuing authority of the token.
• Expiration (exp): The token's expiration time.
• Issued at (iat): The timestamp of when the token was issued.
• Audience (aud): The intended recipient(s) of the token (e.g., your application).
• Scopes/Permissions: Define what the user is allowed to do.

Now that we have the user ID (sub), we could call the auth server again to get the user information by calling Open ID Connect which would provide more user info to our application IF WE DECIDE so, it is not mandatory, but...

Now we are getting to an end, there's 2 important things I want to cover here: Refresh token and Token revocation:

1 - Refresh token
Whenever we receive an access token, there's an option to also receive a refresh token alongside with it, that means now you have 2 tokens, the only difference is that the refresh token doesn't give you access and a longer or no expiration time.

So whenever your access token expires, to avoid that annoying login screen again we just send it alongside with your refresh token to the auth server, so we can retrieve access again without extra user effort.

2 - Token revocation
This is an endpoint on the authorisation server that works for expiring your tokens immediately, so whenever calling this endpoint, your access token expires at the authorisation server, meaning further checks on it will obtain a negative scenario.
PS: Usually the refresh token expires when this is called.

Okay, I guess that would do for now, here is what we covered so far:

1 - Token types
2 - Token structure
3 - Roles
4 - Open Id is a decision
5 - Token refreshment
6 - Token revokation

That is a lot of crucial steps on understanding authentication/auth, I hope that helps anyone on understanding, please leave comments and suggestions on how to improve !