As we said earlier, when a service wants to get access to another service without any user intervention, we can use a CCG flow.

The idea behind CCG is that a service can authenticate to an authentication service exactly like a user would do, and ask for a token that it can then use to authenticate against other services.

A token is a like a password. It's proof that you are allowed to access a particular resource. Whether you are a user or a microservice, if you own a token that the resource recognizes, it's your key to access that resource.

Tokens can hold any information that is useful for the authentication and authorization process. Some of them can be:

• The user name or ID, if it's pertinent to the context
• The scope, which indicates what the caller is allowed to do (read, write, and so on)
• A timestamp indicating when the token was issued
• An expiration timestamp, indicating how long the token is valid

A token is usually built as a self-contained proof that you can use a service. Self-contained means that the service will be able to validate the token without having to call an external resource, which is an excellent way to avoid adding dependencies between services. Depending on the implementation, a token can also be used to access different microservices.

OAuth2 uses the JWT standard for its tokens.