I came across the concept of tokens recently. I am a bit overwhelmed by all these different concepts and would like to seek for your help.

I understood there are tokens that we use for authentication and authorization e.g. Oauth 2.0 (ID token, access token and refresh token).

On the other hand I understood that it's best to use tokens for communication among (micro)services when they call each other. Or e.g. on AWS when a microservice is calling a database/storage?

Can someone give me a high level summary about the use cases of all these concepts please? That would help me to link the information that are being available online to a use case.

CodePudding user response：

The token can be either:

• a pre-shared key
• a self-sufficient entry that is signed by a trusted authority (trusted in your context).

The pre-shared is less and less use because it is sensitive, it is a secret hard to rotate and difficult to protect, it requires this secret to be stored.

Signed self-sufficient token are widely used, for example JWT is a technology for the same.

The authentication and authorization creates a json document, signs it with its private key. The document will say who is authorized, to what and how long. This token is readable by anyone (it is just rotated before being sent).

The client will then send all its request to the service needed. These services will verify that the token receive is valid, in case of a JWT, simply reading it and checking the signature vs the signer public key and the content. This is the usual way we do it for service we develop.

In AWS, with STS and IAM, however, the token only contains the authentication, and authorization will be recomputed at any time.

CodePudding user response：

In OAuth 2.0 a user of an application authenticates through their browser with a standalone auth server and not with an application itself. In other words, the application outsources the task of maintaining a database of valid users and their passwords to the auth server. Tokens are a result of this separation of responsibilities. Tokens are like the old fashioned letters of recommendation given to the bearer with a signature and a seal of the issuer.

In OAuth 2.0, there are three token types:

ID Token - issued when a user authenticates with the auth server. These are self-contained JWT tokens that have information about the user, e.g. user name and email. They are signed by the auth server and have a short expiry. They would be immediately used by the application to verify that the user has authenticated to the auth server. The application would verify token signature to make sure it has been issued by the auth server where the application sent the user to. The application would then extract user information and establish a session with the user. An ID token can be discarded at this point. In other words ID tokens are single use only.

Access tokens - if an application needs to call an API, it needs to obtain an access token on behalf of a user. It would need to contact the auth server and indicate what API it needs and what actions it needs to perform. This may require user to give a consent when auth server requests it. After this the auth server with create an access token. This can be a JWT again with an audience property that identifies the API to be called and a set of scopes that indicate the operations to be performed. This token is also signed. The application sill send the access token to the API. Th API will validate token signature and will only return data or perform an action if it is valid and if the audience and scope are correct. Sometimes access tokens are just opaque strings with no internal structure, just a signature. They simply say, yes, the permission has been granted to access the API. The benefit of using access tokens is that the API does not need to know who the user is and does not need to authenticate a user. user credentials are only submitted once to the auth server and the system at large never sees them.

Refresh token - access tokens have a disadvantage - anyone who has them can call an API many times. To reduce risk of tokens being leaked in logs or stolen, they have a short expiry time, a few minutes. After access token expires, a refresh token is used to silently obtain a new access token from the auth server. A refresh token is issued with the first access token and then is used to obtain a new access token every few minutes. Refresh tokens are also used by the auth server to revoke access if the server detects that user's access token has been compromised and used from a different IP address, etc. Auth server maintains a refresh token for each user and sets a flag against a token whose user has been found compromised either by an admin or by monitoring.

When you have several micro-services that need to call each other, they can also use access tokens to get permission to call each other. This is a machine-to-machine interaction that does not involve a user but it works in a similar way with each service having its own identity on the auth server with its own secret/password. You do not have refresh tokens in this scenario because services can obtain new access tokens using their credentials each time.

See the OAuth 2.0 spec RFC 6749 for details: https://datatracker.ietf.org/doc/html/rfc6749