Definition and and in Google Context :
Access tokens (which aren't always JWTs) are used to inform an API that the bearer of the token has been authorized to access the API and perform a predetermined set of actions (specified by the scopes granted).
Access tokens must never be used for authentication. Access tokens
cannot tell if the user has authenticated.
In Google Context, an OAuth 2.0 access token is useful for
authenticating access from a service account to Google Cloud APIs.
ID tokens are used in token-based authentication. These tokens are signed JSON Web Tokens JWT used to assert identity and do not necessarily carry any implicit authorization against a resource. These tokens will just declare who the caller is and any service that the token is sent to can verify the token's integrity by verifying the signature payload provided with the JWT. The application receives an ID token after a user successfully authenticates, then consumes the ID token and extracts user information from it, which it can then use to personalize the user's experience.
- The aud: field describes the service name this token was created to
invoke. If a service receives an id_token, it must verify its
integrity (signature), validity (is it expired) and if the aud: field
is the predefined name it expects to see. If the names do not match,
the service should reject the token as it could be a replay intended
for another system.
- In Google Context, an OIDC ID token is useful for authenticating the
identity of a service account to services that accept OpenID Connect.
Consider the following example use case for
- Access token :
To get elevated permissions on a project, a service administrator can impersonate a service account to call Google Cloud APIs by creating an OAuth 2.0 access token belonging to that service account. The token has a short lifetime so that the elevated permissions are temporary. Using short-lived tokens helps you implement the principle of least privilege across your identities and resources. It can also be useful when there is an emergency in a production environment, and a service administrator needs a short-term elevated authorization for debugging.
- ID Token :
By creating an OIDC ID token belonging to a service account, a service running on Google Cloud can authenticate itself to another service deployed on a third-party cloud provider, such as a data pipeline job. If the target service is configured with OIDC, the authentication will succeed.
Coming on to the gcloud CLI commands :
- gcloud credentials and application default credentials are managed
separately.
- If you activated a service account key file this only can be used for
gcloud commands but not for application default credentials.
- gcloud auth application-default set of commands are there only to
manage application default and having nothing to do with commands in
gcloud auth
- gcloud auth application-default print-access-token
- This obtains your credentials via a web flow and stores them in 'the
well-known location for Application Default Credentials'.'The
well-known location for Application Default Credentials' is a file
named application_default_credentials.json located in your local
~/.config/gcloud/ directory. Now any code/SDK you run will be able to
find the credentials automatically. This is a good stand-in when you
want to locally test code which would normally run on a server and
use a server-side credentials file. In these cases gcloud auth
application-default print-access-token works as it authenticates with
a user identity (via a web flow) but using the credentials as a proxy
for a service account.
- gcloud auth print-access-token
- Displays the current service account's access token.
- gcloud auth print-identity-token
Print an identity token for the specified account. If not specified,
the current active account will be used.
Both Google Service Accounts and Users can get id_tokens but with an
important distinction: User login oauth flows issue id_tokens
statically bound to the web or oauth2 client_id the flow as
associated with. That is, if a user logs into a web application
involving oauth2, the id_token that the provider issues to the
browser will have the aud: field bound to the oauth2 client_id.
Service Accounts on the other hand, can participate in a flow where
it can receive an id_token from google with an aud: field specified
earlier.
You can print identitytoken using gcloud command for service
accounts, impersonated service accounts and compute engine instances.