Using OAuth 2.0 for Server to Server Applications | Google Identity

Important: If you are working with Google Cloud Platform, unless you plan to build your own client library, use service accounts and a Cloud Client Library instead of performing authorization explicitly as described in this document. For more information, see Authentication Overview in the Google Cloud Platform documentation. With some Google APIs, you can make authorized API calls using a signed JWT instead of using OAuth 2.0, which can save you a network request. See

The Google OAuth 2.0 system supports server-to-server interactions such as those between a web application and a Google service. For this scenario you need a service account, which is an account that belongs to your application instead of to an individual end user. Your application calls Google APIs on behalf of the service account, so users aren't directly involved. This scenario is sometimes called "two-legged OAuth," or "2LO." (The related term "three-legged OAuth" refers to scenarios in which your application calls Google APIs on behalf of end users, and in which user consent is sometimes required.)

Typically, an application uses a service account when the application uses Google APIs to work with its own data rather than a user's data. For example, an application that uses Google Cloud Datastore for data persistence would use a service account to authenticate its calls to the Google Cloud Datastore API.

Google Workspace domain administrators can also grant service accounts domain-wide authority to access user data on behalf of users in the domain.

This document describes how an application can complete the server-to-server OAuth 2.0 flow by using either a Google APIs client library (recommended) or HTTP.

Addendum: Service account authorization without OAuth.

Overview

To support server-to-server interactions, first create a service account for your project in the API Console. If you want to access user data for users in your Google Workspace account, then delegate domain-wide access to the service account.

Then, your application prepares to make authorized API calls by using the service account's credentials to request an access token from the OAuth 2.0 auth server.

Finally, your application can use the access token to call Google APIs.

Recommendation: Your application can complete these tasks either by using the Google APIs client library for your language, or by directly interacting with the OAuth 2.0 system using HTTP. However, the mechanics of server-to-server authentication interactions require applications to create and cryptographically sign JSON Web Tokens (JWTs), and it's easy to make serious errors that can have a severe impact on the security of your application.

For this reason, we strongly encourage you to use libraries, such as the Google APIs client libraries, that abstract the cryptography away from your application code.

Creating a service account

A service account's credentials include a generated email address that is unique and at least one public/private key pair. If domain-wide delegation is enabled, then a client ID is also part of the service account's credentials.

If your application runs on Google App Engine, a service account is set up automatically when you create your project.

If your application runs on Google Compute Engine, a service account is also set up automatically when you create your project, but you must specify the scopes that your application needs access to when you create a Google Compute Engine instance. For more information, see Preparing an instance to use service accounts.

If your application doesn't run on Google App Engine or Google Compute Engine, you must obtain these credentials in the Google API Console. To generate service-account credentials, or to view the public credentials that you've already generated, do the following:

Open the Service accounts page.If prompted, select a project, or create a new one.Click add Create service account.Under Service account details, type a name, ID, and description for the service account, then clickCreate.Optional: Under Service account permissions, select the IAM roles to grant to the service account, then clickContinue.Optional: Under Grant users access to this service account, add the users or groups that are allowed to use and manage the service account.Click add Create key, then clickCreate.

Your new public/private key pair is generated and downloaded to your machine; it serves as the only copy of the private key. You are responsible for storing it securely. If you lose this key pair, you will need to generate a new one.

If you need to grant G Suite domain-wide authority to the service account, click the email address of the service account that you created, then copy the value from the Unique ID box.

To delegate authority to the service account, use the value you copied as the client ID.

You can return to theAPI Console at any time to view the email address, public key fingerprints, and other information, or to generate additional public/private key pairs. For more details about service account credentials in the API Console, see Service accounts in the API Console help file.

Take note of the service account's email address and store the service account's private key file in a location accessible to your application. Your application needs them to make authorized API calls.

Note: You must store and manage private keys securely in both development and production environments. Google does not keep a copy of your private keys, only your public keys. Seethe Handle client credentials securely section of OAuth 2.0 Policies for more information.

Delegating domain-wide authority to the service account

Note: When you use Google Workspace Marketplace to install an application for your domain, the required permissions are automatically granted to the application during installation. You do not need to manually authorize the service accounts that the application uses.Note: Although you can use service accounts in applications that run from a Google Workspace domain, service accounts are not members of your Google Workspace account and aren't subject to domain policies set by Google Workspace administrators. For example, a policy set in the Google Workspace Admin console to restrict the ability of Google Workspace end users to share documents outside of the domain would not apply to service accounts.

If you have a Google Workspace account, an administrator of the organization can authorize an application to access user data on behalf of users in the Google Workspace domain. For example, an application that uses the Google Calendar API to add events to the calendars of all users in a Google Workspace domain would use a service account to access the Google Calendar API on behalf of users. Authorizing a service account to access data on behalf of users in a domain is sometimes referred to as "delegating domain-wide authority" to a service account.

To delegate domain-wide authority to a service account, first enable domain-wide delegation for an existing service account in the Service accounts page or create a new service account with domain-wide delegation enabled.

Then, a super administrator of the Google Workspace domain must complete the following steps:

From your Google Workspace domain'sAdmin console,go to Main menu menu > Security > API Controls.In the Domain wide delegation pane, select Manage Domain Wide Delegation.Click Add new.In the Client ID field, enter the service account's Client ID. You can find your service account's client ID in theService accounts page.In the OAuth scopes (comma-delimited) field, enter the list of scopes that your application should be granted access to. For example, if your application needs domain-wide full access to the Google Drive API and the Google Calendar API, enter:https://www.googleapis.com/auth/drive, https://www.googleapis.com/auth/calendar.Click Authorize.Note: It usually takes a few minutes for impersonation access to be granted after the client ID was added, but in some cases, it might take up to 24 hours to propagate to all users of your Google Account.

Your application now has the authority to make API calls as users in your domain (to "impersonate" users). When you prepare to make authorized API calls, you specify the user to impersonate.

Preparing to make an authorized API call

import com.google.api.client.googleapis.auth.oauth2.GoogleCredential;import com.google.api.services.sqladmin.SQLAdminScopes;// ...GoogleCredential credential = GoogleCredential.fromStream(new FileInputStream("MyProject-1234.json")) .createScoped(Collections.singleton(SQLAdminScopes.SQLSERVICE_ADMIN));GoogleCredential credential = GoogleCredential.fromStream(new FileInputStream("MyProject-1234.json")) .createScoped(Collections.singleton(SQLAdminScopes.SQLSERVICE_ADMIN)).createDelegated("user@example.com"); Create a Credentials object from the service account's credentials and the scopes your application needs access to. For example:from google.oauth2 import service_accountSCOPES = ['https://www.googleapis.com/auth/sqlservice.admin']SERVICE_ACCOUNT_FILE = '/path/to/service.json'credentials = service_account.Credentials.from_service_account_file( SERVICE_ACCOUNT_FILE, scopes=SCOPES)

If you are developing an app on Google Cloud Platform, you can use the application default credentials instead, which can simplify the process.

Delegate domain-wide authority

If you have delegated domain-wide access to the service account and you want to impersonate a user account, use the with_subject method of an existing ServiceAccountCredentials object. For example:

delegated_credentials = credentials.with_subject('user@example.org')

Recommendation: Although your application can complete these tasks by directly interacting with the OAuth 2.0 system using HTTP, the mechanics of server-to-server authentication interactions require applications to create and cryptographically sign JSON Web Tokens (JWTs), and it's easy to make serious errors that can have a severe impact on the security of your application.

For this reason, we strongly encourage you to use libraries, such as the Google APIs client libraries, that abstract the cryptography away from your application code.

Create a JSON Web Token (JWT, pronounced, "jot") which includes a header, a claim set, and a signature.Request an access token from the Google OAuth 2.0 Authorization Server.Handle the JSON response that the Authorization Server returns.{Base64url encoded header}.{Base64url encoded claim set}.{Base64url encoded signature}{Base64url encoded header}.{Base64url encoded claim set}{"alg":"RS256","typ":"JWT"}eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9 NameDescription aud

A descriptor of the intended target of the assertion. When making an access token request this value is always https://oauth2.googleapis.com/token.

{ "iss": "761326798069-r5mljlln1rd4lrbhg75efgigp36m78j5@developer.gserviceaccount.com", "scope": "https://www.googleapis.com/auth/devstorage.read_only", "aud": "https://oauth2.googleapis.com/token", "exp": 1328554385, "iat": 1328550785}{ "iss": "761326798069-r5mljlln1rd4lrbhg75efgigp36m78j5@developer.gserviceaccount.com", "sub": "some.user@example.com", "scope": "https://www.googleapis.com/auth/prediction", "aud": "https://oauth2.googleapis.com/token", "exp": 1328554385, "iat": 1328550785}{ "iss": "761326798069-r5mljlln1rd4lrbhg75efgigp36m78j5@developer.gserviceaccount.com", "scope": "https://www.googleapis.com/auth/prediction", "aud": "https://oauth2.googleapis.com/token", "exp": 1328554385, "iat": 1328550785}{Base64url encoded header}.{Base64url encoded claim set}{Base64url encoded header}.{Base64url encoded claim set}.{Base64url encoded signature}{"alg":"RS256","typ":"JWT"}.{"iss":"761326798069-r5mljlln1rd4lrbhg75efgigp36m78j5@developer.gserviceaccount.com","scope":"https://www.googleapis.com/auth/prediction","aud":"https://oauth2.googleapis.com/token","exp":1328554385,"iat":1328550785}.[signature bytes]eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiI3NjEzMjY3OTgwNjktcjVtbGpsbG4xcmQ0bHJiaGc3NWVmZ2lncDM2bTc4ajVAZGV2ZWxvcGVyLmdzZXJ2aWNlYWNjb3VudC5jb20iLCJzY29wZSI6Imh0dHBzOi8vd3d3Lmdvb2dsZWFwaXMuY29tL2F1dGgvcHJlZGljdGlvbiIsImF1ZCI6Imh0dHBzOi8vd3d3Lmdvb2dsZWFwaXMuY29tL29hdXRoMi92NC90b2tlbiIsImV4cCI6MTMyODU1NDM4NSwiaWF0IjoxMzI4NTUwNzg1fQ.UFUt59SUM2_AW4cRU8Y0BYVQsNTo4n7AFsNrqOpYiICDu37vVt-tw38UKzjmUKtcRsLLjrR3gFW3dNDMx_pL9DVjgVHDdYirtrCekUHOYoa1CMR66nxep5q5cBQ4y4u2kIgSvChCTc9pmLLNoIem-ruCecAJYgI9Ks7pTnW1gkOKs0x3YpiLpzplVHAkkHztaXiJdtpBcY1OXyo6jTQCa3Lk2Q3va1dPkh_d--GU2M5flgd8xNBPYw4vxyt0mP59XZlHMpztZt0soSgObf7G3GXArreF_6tpbFsS3z2t5zkEiHuWJXpzcYr5zWTRPDEHsejeBSG8EgpLDce2380ROQ https://oauth2.googleapis.com/token NameDescription grant_type

Use the following string, URL-encoded as necessary: urn:ietf:params:oauth:grant-type:jwt-bearer

POST /token HTTP/1.1Host: oauth2.googleapis.comContent-Type: application/x-www-form-urlencodedgrant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer&assertion=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiI3NjEzMjY3OTgwNjktcjVtbGpsbG4xcmQ0bHJiaGc3NWVmZ2lncDM2bTc4ajVAZGV2ZWxvcGVyLmdzZXJ2aWNlYWNjb3VudC5jb20iLCJzY29wZSI6Imh0dHBzOi8vd3d3Lmdvb2dsZWFwaXMuY29tL2F1dGgvcHJlZGljdGlvbiIsImF1ZCI6Imh0dHBzOi8vYWNjb3VudHMuZ29vZ2xlLmNvbS9vL29hdXRoMi90b2tlbiIsImV4cCI6MTMyODU3MzM4MSwiaWF0IjoxMzI4NTY5NzgxfQ.ixOUGehweEVX_UKXv5BbbwVEdcz6AYS-6uQV6fGorGKrHf3LIJnyREw9evE-gs2bmMaQI5_UbabvI4k-mQE4kBqtmSpTzxYBL1TCd7Kv5nTZoUC1CmwmWCFqT9RE6D7XSgPUh_jF1qskLa2w0rxMSjwruNKbysgRNctZPln7cqQcurl -d 'grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer&assertion=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiI3NjEzMjY3OTgwNjktcjVtbGpsbG4xcmQ0bHJiaGc3NWVmZ2lncDM2bTc4ajVAZGV2ZWxvcGVyLmdzZXJ2aWNlYWNjb3VudC5jb20iLCJzY29wZSI6Imh0dHBzOi8vd3d3Lmdvb2dsZWFwaXMuY29tL2F1dGgvcHJlZGljdGlvbiIsImF1ZCI6Imh0dHBzOi8vYWNjb3VudHMuZ29vZ2xlLmNvbS9vL29hdXRoMi90b2tlbiIsImV4cCI6MTMyODU3MzM4MSwiaWF0IjoxMzI4NTY5NzgxfQ.RZVpzWygMLuL-n3GwjW1_yhQhrqDacyvaXkuf8HcJl8EtXYjGjMaW5oiM5cgAaIorrqgYlp4DPF_GuncFqg9uDZrx7pMmCZ_yHfxhSCXru3gbXrZvAIicNQZMFxrEEn4REVuq7DjkTMyCMGCY1dpMa8aWfTQFt3Eh7smLchaZsU' https://oauth2.googleapis.com/token { "access_token": "1/8xbJqaOZXSUZbHLl5EOtu1pxz3fmmetKx9W8CV4t79M", "scope": "https://www.googleapis.com/auth/prediction" "token_type": "Bearer", "expires_in": 3600}

Calling Google APIs

Create a service object for the API that you want to call using the GoogleCredential object. For example:SQLAdmin sqladmin = new SQLAdmin.Builder(httpTransport, JSON_FACTORY, credential).build();Make requests to the API service using the interface provided by the service object. For example, to list the instances of Cloud SQL databases in the exciting-example-123 project:SQLAdmin.Instances.List instances = sqladmin.instances().list("exciting-example-123").execute(); Build a service object for the API that you want to call. You build a a service object by calling the build function with the name and version of the API and the authorizedCredentials object. For example, to call version 1beta3 of the Cloud SQL Administration API:import googleapiclient.discoverysqladmin = googleapiclient.discovery.build('sqladmin', 'v1beta3', credentials=credentials)Make requests to the API service using the interface provided by the service object. For example, to list the instances of Cloud SQL databases in the exciting-example-123 project:response = sqladmin.instances().list(project='exciting-example-123').execute() GET /drive/v2/files HTTP/1.1Host: www.googleapis.comAuthorization: Bearer access_tokenGET https://www.googleapis.com/drive/v2/files?access_token=access_tokencurl -H "Authorization: Beareraccess_token" https://www.googleapis.com/drive/v2/filescurl https://www.googleapis.com/drive/v2/files?access_token=access_token

JWT error codes

error fielderror_description fieldMeaningHow to resolve unauthorized_clientUnauthorized client or scope in request.

If you're trying to use domain-wide delegation, the service account is not authorized in the Admin console of the user's domain.

Ensure that the service account is authorized in theDomain-wide delegation page of the Admin console for the user in the sub claim (field).

While it usually takes a few minutes, it might take up to 24 hours for authorization to propagate to all users in your Google Account.

unauthorized_clientClient is unauthorized to retrieve access tokens using this method, or client not authorized for any of the scopes requested.

A service account was authorized using the client email address rather than the client ID (numeric) in the Admin console.

In theDomain-wide delegation page in the Admin console, remove the client, and re-add it with the numeric ID.

access_denied

(any value)

If you're using Domain-wide delegation, one or more requested scopes aren't authorized in the Admin console.

Ensure that the service account is authorized in theDomain-wide delegation page of the Admin console for the user in the sub claim (field), and that it includes all of the scopes you're requesting in the scope claim of your JWT.

While it usually takes a few minutes, it might take up to 24 hours for authorization to propagate to all users in your Google Account.

invalid_grantNot a valid email.

The user doesn't exist.

Check that the email address in the sub claim (field) is correct.

invalid_grant

Invalid JWT: Token must be a short-lived token (60 minutes) and in a reasonable timeframe. Check your 'iat' and 'exp' values and use a clock with skew to account for clock differences between systems.

Usually, it means that the local system time is not correct. It could also happen if the exp value is more than 65 mins in the future from the iat value, or the exp value is lower than iat value.

Make sure that the clock on the system where the JWT is generated is correct. If necessary, sync your time with Google NTP.

invalid_grantInvalid JWT Signature.

The JWT assertion is signed with a private key not associated with the service account identified by the client email or the key that was used has been deleted, disabled, or has expired.

Alternatively, the JWT assertion might be encoded incorrectly - it must be Base64-encoded, without newlines or padding equal signs.

Decode the JWT claim set and verify the key that signed the assertion is associated with the service account.

Try to use a Google-provided OAuth library to make sure the JWT is generated correctly.

invalid_scopeInvalid OAuth scope or ID token audience provided.

No scopes were requested (empty list of scopes), or one of the requested scopes doesn't exist (i.e. is invalid).

Ensure that the scope claim (field) of the JWT is populated, and compare the scopes that it contains with the documented scopes for the APIs you want to use, to ensure there are no errors or typos.

Note that the list of scopes in the scope claim needs to be separated by spaces, not commas.

disabled_clientThe OAuth client was disabled.

The key used to sign the JWT assertion is disabled.

Go to the Google API Console, and under IAM & Admin > Service Accounts, enable the service account which contains the "Key ID" used to sign the assertion.

Addendum: Service account authorization without OAuth

With some Google APIs, you can make authorized API calls using a signed JWT directly as a bearer token, rather than an OAuth 2.0 access token. When this is possible, you can avoid having to make a network request to Google's authorization server before making an API call.

If the API you want to call has a service definition published in the Google APIs GitHub repository, you can make authorized API calls using a JWT instead of an access token. To do so:

Create a service account as described above. Be sure to keep the JSON file you get when you create the account.Using any standard JWT library, such as one found at jwt.io, create a JWT with a header and payload like the following example:{ "alg": "RS256", "typ": "JWT", "kid": "abcdef1234567890"}.{ "iss": "123456-compute@developer.gserviceaccount.com", "sub": "123456-compute@developer.gserviceaccount.com", "aud": "https://firestore.googleapis.com/", "iat": 1511900000, "exp": 1511903600}For the kid field in the header, specify your service account's private key ID. You can find this value in theprivate_key_id field of your service account JSON file.For the iss and sub fields, specify your service account's email address. You can find this value in theclient_email field of your service account JSON file.For the aud field, specify the API endpoint. For example:https://SERVICE.googleapis.com/.For the iat field, specify the current Unix time, and for theexp field, specify the time exactly 3600 seconds later, when the JWT will expire.

Sign the JWT with RSA-256 using the private key found in your service account JSON file.

For example:

GoogleCredential credential = GoogleCredential.fromStream(new FileInputStream("MyProject-1234.json"));PrivateKey privateKey = credential.getServiceAccountPrivateKey();String privateKeyId = credential.getServiceAccountPrivateKeyId();long now = System.currentTimeMillis();try { Algorithm algorithm = Algorithm.RSA256(null, privateKey); String signedJwt = JWT.create() .withKeyId(privateKeyId) .withIssuer("123456-compute@developer.gserviceaccount.com") .withSubject("123456-compute@developer.gserviceaccount.com") .withAudience("https://firestore.googleapis.com/") .withIssuedAt(new Date(now)) .withExpiresAt(new Date(now + 3600 * 1000L)) .sign(algorithm);} catch ...

Using PyJWT:

iat = time.time()exp = iat + 3600payload = {'iss': '123456-compute@developer.gserviceaccount.com', 'sub': '123456-compute@developer.gserviceaccount.com', 'aud': 'https://firestore.googleapis.com/', 'iat': iat, 'exp': exp}additional_headers = {'kid': PRIVATE_KEY_ID_FROM_JSON}signed_jwt = jwt.encode(payload, PRIVATE_KEY_FROM_JSON, headers=additional_headers, algorithm='RS256')Call the API, using the signed JWT as the bearer token: GET /v1/projects/abc/databases/123/indexes HTTP/1.1Authorization: BearerSIGNED_JWT Host: firestore.googleapis.com