すべてのDFP API には OAuth 2.0認証が必要です.
略
OAuth 2.
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:
- Visit Google Developers Console.
- Click CREATE PROJECT to create a new project.
- Enter the Project Name (and optionally, choose your own Project ID), and click Create.
- The newly created project should automatically open. Click APIs & auth to expand the menu, and then click Credentials.
- Click CREATE NEW CLIENT ID to create a new Client ID and client secret.
- Choose Installed Application with type Other. Click CREATE CLIENT ID to complete the registration.
- Client ID and client secret will be created and displayed.
- 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:
- Put the corresponding Client ID and client secret into the client library's configuration file.
- Run the client library utility.
- The utility will point you to a Google consent page asking you to grant permission to the application.
- Click Accept to grant permission to the application.
- Google will provide you an authorization code in the webpage.
- Copy and paste the authorization code back to the client library utility.
- After entering the authorization code in the client library utility, it will then print out the refresh token.
- Store the offline refresh token in the client library's configuration file.
The following table provides detailed instructions on using OAuth 2.0 in different client libraries:
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. | 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.
