Search code examples
authenticationgoogle-cloud-platformgcloudgoogle-authentication

gcloud identity token vs access token

What is the difference between access-token and identity-token when we use gcloud auth print-access-token and gcloud auth print-identity-token?

What are the cases where we can use one and not the other in Google Cloud context.

Why we have print-access-token for gcloud auth and gcloud auth application-default while we have print-identity-token only for gcloud auth

Solution

  • 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.

    1. 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.
    2. 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

    1. 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.

    1. 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
    1. 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.
    1. gcloud auth print-access-token
    • Displays the current service account's access token.
    1. 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.