Basic rules
When developers use Application Open Platform, they must take note of the following rules:
Application Open Platform provides resources and services to developers by calling API operations on the server.
Developers can read and write user information only after they are granted the corresponding permissions by users.
Open Authorization (OAuth) 2.0 is used to grant developers the permissions to read and write user information in miniapps. This way, developers can obtain the basic information and business data of users.
OAuth 2.0
OAuth 2.0 is a specification that is used for resource authorization. OAuth defines a secure, open, and simple standard for resource authorization. If you use OAuth to grant the permissions on user resources to a third-party application, the third-party application can obtain the authorized information without the need to obtain the account and password of the user.
OAuth 2.0 is a delegated authorization framework that is used for RESTful APIs.
OAuth 2.0 is a token-based authorization method that allows applications to obtain limited access to user data without the need to expose the password of the user.
OAuth 2.0 decouples authentication and authorization.
Terms in OAuth2.0
The following terms are commonly used in OAuth2.0 scenarios:
Third-party application: A third-party application is also known as client.
Resource owner: A resource owner is a user.
HTTP service: A service provider who owns the resource server and can provide user information.
Authorization server: An authorization server is a server that is provided by a service provider to process authorization.
Resource server: A resource server is a server that is used to store the resources that are generated by a user. A resource server is deployed in a different logic node from an authorization server. The servers can reside in the same physical node.
User agent: In most cases, a user agent refers to a browser.
Client credentials: Client credentials are the client ID, password, and authorization code that are used to authenticate users.
Access token: An access token is a token that is issued by the authorization service provider after the provider receives a user request.
Refresh token: You can refresh an existing token to obtain a new token. A token expires in a short period of time. When a token is expired, the process that needs to be performed to obtain a new token is complex. To improve user experience, you can refresh a token to obtain a new token.
Methods supported by OAuth 2.0 to obtain a token
A client can obtain a token only after the client is granted the corresponding permissions by the user.
A developer can select one of the following methods that are specified in OAuth 2.0 to issue a token to a third-party application:
The authorization code method: The most common method. Token refreshing is supported.
The implicit code method: The method is designed for web browsers. Token refreshing is not supported.
The password method: The method is designed for legacy systems. Token refreshing is supported.
The client credentials method: The method is designed for API services. Token refreshing is not supported.
Authorization procedure by using OAuth
In a miniapp scenario, you can use the authorization code method to grant the permissions on user resources to a third-party application. Compared with other methods, the authorization code method is the most common and secure method. The following figure describes the procedure for granting the permissions on user resources to a third-party application.
The following items describe the roles that the services in the miniapp assume based on OAuth 2.0:
Resource owner: the user of the miniapp.
Resource server: the server of Supperapp.
Authorization server: This role is assumed by the Supperapp server.
HTTP service: This role is assumed by the Supperapp server.
Third-party application: the miniapp of the merchant.
User Agent: Supperapp.
Authorize a merchant to call an API operation
The following figure shows how to authorize a merchant to call an API operation.
