Drive and Photo Service:OAuth 2.0 access process for web server applications

Step 1: Get the application ID and Secret

1. Go to the domain list of the Drive and Photo Service.

2. Find the domain you want, and click Details in the Actions column.

3. Create an application.

   1. On the domain details page, click the Applications tab, and then click Create Application.

   2. Configure the parameters as prompted, and then click OK.

      Set Type to WebServer (Web Server Application).

      

4. In the application list, get the application ID (client_id) and Secret (client_secret).

   Important

   Keep the Secret confidential and do not disclose it.

   

Step 2: OAuth 2.0 login authorization

1. Set Authorization parameters

   Users access your web service application through a browser. If the user is not authenticated, you need to build an Authorization request for your web service application. This request includes your web service application's client_id and the scope of access to allow the user to authorize your web service application to the PDS Auth service (Authorization Server).

   Request example:

   GET /v2/oauth/authorize?client_id=<ID>&redirect_uri=<redirect_uri>&login_type=<login_type>&scope=<scope>&respoe response:HTTP/1.1 2nse_type=code&state=[state] HTTP/1.1
   Host: {domainId}.api.aliyunpds.com

   Description of the request parameters:

   Parameter	Required	Description
   client_id	Yes	Application ID. For more information, see Get the application ID and Secret.
   redirect_uri	Yes	Callback URL, the address to which the authentication service redirects after authorization, such as https://example.com/callback. After successful authorization, the user is redirected to this address with a one-time verification code, such as https://example.com/callback?code=xxxx. Note Ensure that the callback URL matches the OAuth 2.0 callback URL provided when creating the application.
   scope	No	List of access scopes, describing the access privileges your web service application requires. This parameter is a subset of the permissions filled in when creating the application and is displayed on the user consent page. For more information, see Scopes. Note The final permissions obtained by the AccessToken are the intersection of the entire scope and the user's permissions.
   response_type	Yes	The value is fixed to code.
   state	No, but recommended	If this parameter is included in the request, the authentication server returns it without changing it, to prevent CSRF attacks, such as https://example.com/callback?code=xxxx&state=abc.
   login_type	Yes	Login options. Valid values are as follows: default: For a comprehensive login page, including mobile number login and other methods. phone: Mobile number login only. ding: For DingTalk QR code login. ldap: For LDAP or AD domain login. wx: For WeCom login. ram: For RAM user login. lark: For Lark login. saml: For third-party account login through the SAML protocol.
   hide_consent	No	Whether to skip the user consent page after the first login. Valid values are as follows: true (default): The user will not see the consent page and will proceed directly to the next step. false: The user will see the consent page.
   lang	No	The language in which the interface is displayed. Valid values are as follows: zh_CN (default): Simplified Chinese. en_US: US English.

2. Consent page

   On this page, the user can decide whether to authorize the web service application. If the user refuses to grant the permissions, the process ends. If the user agrees, they will be redirected to the redirect_uri specified in the first step request, such as https://example.com/callback?code=xxxx&state=abc.

3. Get an access token through code

   The web service application consists of frontend and backend parts. The frontend needs to configure the redirection URI https://example.com/callback. After receiving the parameter ?code=xxx, the frontend parses the code and passes it to the backend. The backend then obtains the access token through the following interface and returns it to the frontend:

   Sample request:

   POST /v2/oauth/token HTTP/1.1
   Host: {domainId}.api.aliyunpds.com
   Content-Type: application/x-www-form-urlencoded
   
   code=xxx\
   &client_id=your_app_id\
   &client_secret=your_app_secret\
   &redirect_uri=https://example.com/callback\
   &grant_type=authorization_code

   Parameter	Required	Description
   code	Yes	One-time code, which becomes invalid after use.
   client_id	Yes	Application ID. For more information, see Get the application ID and Secret.
   client_secret	Yes	The Secret generated when the application is created.
   redirect_uri	Yes	Callback URL, the address to which the authentication service redirects after authorization, such as https://example.com/callback. Note Ensure that the callback URL matches the OAuth 2.0 callback URL provided when creating the application.
   grant_type	Yes	The type of authorization. The value is fixed to authorization_code, indicating the use of the Authorization Code method.

   Sample response：

   HTTP/1.1 200 OK
   Content-Type: application/json
   
   {
     "access_token":"Aiasd76*****",
     "expires_time":"2019-11-11T10:10:10.009Z",
     "expire_in": 7200,
     "token_type":"Bearer",
     "refresh_token":"LSLKdk*******"
   }

   Parameter	Location	Type	Required	Description
   access_token	body	string	Yes	The generated access token, valid for 2 hours.
   refresh_token	body	string	Yes	Used to refresh the access token, with a longer validity period, generally 7 days.
   expires_time	body	string	Yes	The expiration time of the access token.
   expire_in	body	long	Yes	The validity period of the access token. Default: 7200. Unit: seconds.
   token_type	body	string	Yes	The type of token. The value is fixed to Bearer.

4. Call the PDS APIs

   The web frontend can directly use the access token to call the PDS APIs by including the access_token in the Authorization request header.

   For more information, see Call methods.

Refresh the access token

Sample request:

POST /v2/oauth/token HTTP/1.1
Host: {domainId}.api.aliyunpds.com
Content-Type: application/x-www-form-urlencoded

refresh_token=xxx\
&client_id=xxx\
&client_secret=xxx\
&grant_type=refresh_token

Description of the request parameters:

Sample response：

HTTP/1.1 200 OK
Content-Type: application/json

{
  "access_token":"xxxxxxxxx",
  "refresh_token": "xxxxx",
  "expires_in":7200,
  "expire_time":"2019-11-11T10:10:10.009Z",
  "token_type":"Bearer"
}

The description of the response parameters is the same as that of the request parameters.