DFPリファレンス日本語訳 ５

認証

• 目次
• OAuth 2.0 とDFP APIをはじめる
  • Client IDとclient secretの作成
  • client libraryの設定と使用
• Behind the scenes

すべてのDFP API には OAuth 2.0認証が必要です.

略

OAuth 2.0 とDFP APIをはじめる

OAuth 2.0とclient librariesを併用するには:

• Client IDと client secretの作成.
•  client libraryの設定.

Create a Client ID and client secret

To use OAuth 2.0 to authorize the DFP API, you must first create a Client ID and a client secret:

1. Visit Google Developers Console.
2. Click CREATE PROJECT to create a new project.
   
3. Enter the Project Name (and optionally, choose your own Project ID), and click Create.
   
4. The newly created project should automatically open. Click APIs & auth to expand the menu, and then click Credentials.
   
5. Click CREATE NEW CLIENT ID to create a new Client ID and client secret.
   
6. Choose Installed Application with type Other. Click CREATE CLIENT ID to complete the registration.
   
7. Client ID and client secret will be created and displayed.
   
   Warning: A client secret can grant acesss to your DFP account. It should be treated as a credential of the user and stored securely. Do not share your client secret.
8. Make sure all of the required fields are filled and saved for the Consent Screen.
   

Configure and use a client library

Follow these steps for the OAuth 2.0 Installed application flow:

1. Put the corresponding Client ID and client secret into the client library's configuration file.
   JAVAPHP.NETPYTHONRUBY

   
   

   See ads.properties.
2. Run the client library utility.
   JAVAPHP.NETPYTHONRUBY

   
   

   See GetRefreshToken.java.
3. The utility will point you to a Google consent page asking you to grant permission to the application.
   
   Important: You should be logged in as the DFP account user, so that the generated OAuth 2.0 code will be associated with this user.
4. Click Accept to grant permission to the application.
5. Google will provide you an authorization code in the webpage.
   
6. Copy and paste the authorization code back to the client library utility.
7. After entering the authorization code in the client library utility, it will then print out the refresh token.
8. Store the offline refresh token in the client library's configuration file.
   Warning: Each refresh token is user-specific and should be stored securely just like any other user credential. A refresh token can be used to retrieve an access token on the user's behalf and so allows your application to access the user's DFP account.

The following table provides detailed instructions on using OAuth 2.0 in different client libraries:

OAuth 2.0 Usage Guide	OAuth 2.0 Utility
Java	Java
PHP	PHP
.NET	.NET
Python	Python
Ruby	Ruby

Behind the scenes

Our client libraries automatically take care of the details covered below so only read on if you're interested in what's happening behind the scenes. This section is intended for advanced users who are already familiar with the OAuth 2.0 specification and know how to use OAuth 2.0 with Google APIs.

Scope

A single access token can grant varying degrees of access to multiple APIs. A variable parameter called scope controls the set of resources and operations that an access token permits. During the access token request, your application sends one or more values in thescope parameter.

The scope for the DFP API is:

Scope	Meaning
https://www.googleapis.com/auth/dfp	Read/write access to DFP API.

Offline access

It is common for a DFP API client application to request offline access. For example, your DFP API client application may want to run batch jobs when your user is not physically online browsing your website.

To request offline access for a Web application type, make sure you set the access_typeparameter to offline. You can find additional information in Google's OAuth 2.0 guide.

For Installed application type, offline access is enabled by default - you don't have to explicitly request offline access.

HTTP request header

The HTTP header in every request to the DFP API server must include the access token in this form:

Authorization: Bearer THE_ACCESS_TOKEN

For example:

POST … HTTP/1.1
Host: …
Authorization: Bearer 1/fFAGRNJru1FTz70BzhT3ZgContent-Type: text/xml;charset=UTF-8
Content-Length: …
<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope">
  …
</soap:Envelope>

Access and refresh token

In most DFP API use cases, you will need to store the refresh token securely for future use. To learn more about how to request access and refresh tokens, read the guide that is relevant to your application type:

• Installed application (recommended)
• Web application with a web flow

Access token expiration

An access token has an expiration time (based on the expires_in value) after which the token is no longer valid. You can use the refresh token to refresh an expired access token. By default, our client libraries automatically refresh an expired access token.