検索
検索をクリア
検索終了
Google アプリ
メインメニュー
true
リクエストしたページはお使いの言語では現在利用できません。Google Chrome に組み込まれている翻訳機能を使用すると、ウェブページをお好きな言語にすぐに翻訳できます。

Setting up OAuth 2.0

To use OAuth 2.0 in your application, you need an OAuth 2.0 client ID, which your application uses when requesting an OAuth 2.0 access token.

To create an OAuth 2.0 client ID in the console:

  1. Go to the API Console.
  2. From the projects list, select a project or create a new one.
  3. If the APIs & services page isn't already open, open the console left side menu and select APIs & services.
  4. On the left, click Credentials.
  5. Click New Credentials, then select OAuth client ID.

    Note: If you're unsure whether OAuth 2.0 is appropriate for your project, select Help me choose and follow the instructions to pick the right credentials.

  6. Select the appropriate application type for your project and enter any additional information required. Application types are described in more detail in the following sections.
  7. If this is your first time creating a client ID, you can also configure your consent screen by clicking Consent Screen. (The following procedure explains how to set up the Consent screen.) You won't be prompted to configure the consent screen after you do it the first time.
  8. Click Create client ID

To delete a client ID, go to the Credentials page, check the box next to the ID, and then click Delete.

User consent

When you use OAuth 2.0 for authentication, your users are authenticated after they agree to terms presented to them on a user consent screen.

To set up your project's consent screen:

  1. Go to the API Console Credentials page.
  2. On the left, click Credentials.
  3. Click OAuth consent screen.
  4. Fill out the form and then click Save.

Note: The consent screen settings within the console are set at the project level, so the information that you specify on the Consent screen page applies across the entire project.

For more information about user authentication, see the OAuth 2.0 documentation.

Service accounts, web applications, and installed applications

For information about setting up service accounts, web applications, or installed applications, see the following topics.

Service accounts

A service account is used in an application that calls APIs on behalf of an application that does not access user information. This type of application needs to prove its own identity, but it does not need a user to authorize requests.

For example, if your project employs server-to-server interactions such as those between a web application and Google Cloud Storage, then you need a private key and other service account credentials. To generate these credentials, or to view the email address and public keys that you've already generated, do the following:

  1. Open the API Console Credentials page.
  2. If it's not already selected, select the project that you're creating credentials for.
  3. To set up a new service account, click New credentials and then select Service account key.
  4. Choose the service account to use for the key.
  5. Choose whether to download the service account's public/private key as a standard P12 file, or as a JSON file that can be loaded by a Google API client library.

    Your new public/private key pair is generated and downloaded to your machine; it serves as the only copy of this key. You are responsible for storing it securely.

Your project needs the private key when requesting an OAuth 2.0 access token in server-to-server interactions. Google does not keep a copy of this private key, and this screen is the only place to obtain this particular private key. When you click Download private key, the PKCS #12-formatted private key is downloaded to your local machine. As the screen indicates, you must securely store this key yourself.

The name of the downloaded private key is the key's thumbprint. When inspecting the key on your computer, or using the key in your application, you need to provide the password notasecret. Note that while the password for all Google-issued private keys is the same (notasecret), each key is cryptographically unique.

You can generate multiple public-private key pairs for a single service account. This makes it easier to update credentials or roll them over without application downtime. However, you cannot delete a key pair if it is the only one created for that service account.

Use the email address when granting the service account access to supported Google APIs.

For more details, see the OAuth 2.0 Service Accounts documentation.

Note: When you use a service account, you are subject to the Terms of Service for each product, both as an end user and as a developer.

The Google Service accounts documentation contains more detailed information about service accounts.

Web applications

A web application is accessed by web browsers over a network.

  • Applications that use JavaScript to access Google APIs must specify authorized JavaScript origins. The origins identify the domains from which your application can send API requests.
  • Applications that use languages and frameworks like PHP, Java, Python, Ruby, and .NET must specify authorized redirect URIs. The redirect URIs are the endpoints to which the OAuth 2.0 server can send responses.
Installed applications

If your application is going to be installed on a device or computer (such as a system running Microsoft Windows, Apple OS X, Apple iOS, or Android), you can use either of two OAuth 2.0 flows, as described in Google's OAuth 2.0 Installed Applications and Devices documentation.

Chrome

Google Chrome apps and extensions are a special case of installed applications. Chrome exposes JavaScript APIs to allow your Chrome apps and extensions to perform various operations. Some of these APIs rely on knowing the identity of the user who is signed in to Chrome. If you're writing a Chrome app or extension that calls APIs that need to know the user's identity, and you want your app or extension to get user authorization for these requests using OAuth 2.0, then choose Chrome as the platform when you create your credentials. You will need to enter your Chrome app or extension's Application ID. For more information about these APIs, see the Google Chrome Identity API documentation.

Android

Note: Currently, obtaining OAuth 2.0 access tokens via AccountManager works for Android Ice Cream Sandwich (4.0) and newer versions.

You need to specify your Android app's package name and SHA1 fingerprint.

  1. In the Package name field, enter your Android app's package name.
  2. In a terminal, run the Keytool utility to get the SHA1 fingerprint for your digitally signed .apk file's public certificate.

    keytool -exportcert -alias androiddebugkey -keystore path-to-debug-or-production-keystore -list -v

    Note: For the debug.keystore, the password is android. For Eclipse, the debug keystore is typically located at ~/.android/debug.keystore.

    The Keytool prints the fingerprint to the shell. For example:

    $ keytool -exportcert -alias androiddebugkey -keystore ~/.android/debug.keystore -list -v
    Enter keystore password: Type "android" if using debug.keystore
    Alias name: androiddebugkey
    Creation date: Aug 27, 2012
    Entry type: PrivateKeyEntry
    Certificate chain length: 1
    Certificate[1]:
    Owner: CN=Android Debug, O=Android, C=US
    Issuer: CN=Android Debug, O=Android, C=US
    Serial number: 503bd581
    Valid from: Mon Aug 27 13:16:01 PDT 2012 until: Wed Aug 20 13:16:01 PDT 2042
    Certificate fingerprints:
       MD5: 1B:2B:2D:37:E1:CE:06:8B:A0:F0:73:05:3C:A3:63:DD
       SHA1: D8:AA:43:97:59:EE:C5:95:26:6A:07:EE:1C:37:8E:F4:F0:C8:05:C8
       SHA256: F3:6F:98:51:9A:DF:C3:15:4E:48:4B:0F:91:E3:3C:6A:A0:97:DC:0A:3F:B2:D2:E1:FE:23:57:F5:EB:AC:13:30
       Signature algorithm name: SHA1withRSA
       Version: 3

    Copy the SHA1 fingerprint, which is bold in the example above.

    Important: When you prepare to release your app to your users, follow these steps again and create a new OAuth 2.0 client ID for your production app. For production apps, use your own private key to sign the production app's .apk file. For more information, see Signing your applications.

  3. Paste the SHA1 fingerprint into the form where requested.
  4. Click Create.
Apple iOS

If your application accesses APIs directly from iOS, you will need the application's Bundle ID and (optionally) its Apple App Store ID:

  • The application's Bundle ID is the bundle identifier as listed in the app's .plist file. For example: com.example.myapp.
  • The application's App Store ID is in the app's iTunes URL, if the app was published in the Apple iTunes App Store. For example, in the app URL http://itunes.apple.com/us/app/google+/id447119634, the App Store ID is 447119634.
  • The application's Team ID is a 10-character string that Apple assigns to your team. For information about your Team ID, see Locating your Team ID in the Apple App Distribution Guide.

After creating your iOS credentials and obtaining a Client ID, you use the Installed Application OAuth 2.0 flow to communicate with Google APIs.

Other

The console does not require any additional information to create OAuth 2.0 credentials for other types of installed applications.