Combine Alibaba Cloud API Gateway with machine-to-machine (M2M) authentication to strictly control third-party access permissions and enable efficient, secure, and automated communication between systems.
Prerequisites
You have an M2M application server and an M2M application client in IDaaS.
Process overview
Only three steps are required to implement M2M authentication for your API operations, so that the identity of the caller is trusted and its permissions are controllable:
Register the API operation with Alibaba Cloud API Gateway.
Grant permissions to your M2M client.
Bind the API operation that you want to protect to the permission scope of the M2M client by using the plugin configuration in API Gateway.
Configuration example
Register the API operation with API Gateway
Log on to API Gateway. In the left-side navigation pane, choose . Click Create Group.
On the Backend Services tab, click Create Backend Service. This step registers your business service endpoint with Alibaba Cloud API Gateway, which makes it easier to manage the API operations of the business service.
Bind your business service endpoint to the backend service that you created.
After the backend service is created, manage the API operations in the backend service.
To the right of the backend service that you created in the previous step, click Create API. The Create API page appears.
On the Create API page, set security verification to No Authentication and click Next.
When you define the API request, enter the Request Path and select the HTTP Method.
When you define the backend service of the API, enter the actual request path. When a caller invokes the specified request path, the request is mapped to the real path on the backend.
Select the response ContentType to complete the API creation procedure.
You can debug the API that you created in the console to verify that the API operation runs as expected and is available.
Prepare the debugging environment. Select the environment to which you want to publish the API operation and publish it.
Select debugging in the staging environment and send the request.
Grant permissions to the M2M client
Log on to the IDaaS console. Open your M2M server application, find your M2M client application among the authorized applications, and grant it the permission scope.
Configure API Gateway plugins
Configure gateway plugins to authenticate and authorize incoming requests and to associate the M2M permission scope with API Gateway. In this step, create two gateway plugins: the JWT Authentication plugin and the Parametric Access Control plugin.
Create the JWT Authentication plugin
Log on to the API Gateway console. In the left-side navigation pane, choose . On the Plugins page, click Create Plugin and set Plug-in Type to JWT Authentication.
Enter the script configuration. The jwk information in the script configuration must be the same as the public key information of the M2M server. Log on to the IDaaS console. Open your M2M server application, go to Application Settings, and copy the link of the Public Key Endpoint. Open the link in a browser to view the public key information.
Replace the jwk in the following content with the JWT public key information that you obtained.
Script configuration before the replacement
--- parameter: id_token # Obtain the JWT from the specified parameter, which corresponds to the API parameter parameterLocation: query # API in mapping mode, this parameter is optional; in pass-through mode, it is required. Specifies where the JWT is read from. Valid values: `query`,`header` bypassEmptyToken: false # Specifies whether verification is allowed to pass when the `jwt` is empty claimParameters: # claims parameter transformation. The gateway maps JWT claims to backend parameters - claimName: aud # claim name. Public and private claims are supported parameterName: aud # Name of the mapped parameter location: query # Location of the mapped parameter. Supported values: `query,header,path,formData` - claimName: scope # claim name. Public and private claims are supported parameterName: scope # Name of the mapped parameter location: query # Location of the mapped parameter. Supported values: `query,header,path,formData` - claimName: client_id # claim name. Public and private claims are supported parameterName: client_id # Name of the mapped parameter location: query # Location of the mapped parameter. Supported values: `query,header,path,formData` preventJtiReplay: false # Specifies whether to enable the anti-replay check for `jti`. Default value: false # # The following content needs to be replaced jwk: kty: RSA e: AQAB use: sig kid: O8fpdhrViq2zaaaBEWZITz # When only one JWK is configured, kid is optional. However, if the JWT contains a kid, the gateway verifies the consistency of the kid alg: RS256 n: qSVxcknOm0uCq5vGsOmaorPDzHUubBmZZ4UXj-9do7w9X1uKFXAnqfto4TepSNuYU2bA_-tzSLAGBsR-BqvT6w9SjxakeiyQpVmexxnDw5WZwpWenUAcYrfSPEoNU-0hAQwFYgqZwJQMN8ptxkd0170PFauwACOx4Hfr-9FPGy8NCoIO4MfLXzJ3mJ7xqgIZp3NIOGXz-GIAbCf13ii7kSStpYqN3L_zzpvXUAos1FJ9IPXRV84tIZpFVh2lmRh0h8ImK-vI42dwlD_hOIzayL1Xno2R0T-d5AwTSdnep7g-Fwu8-sj4cCRWq3bd61Zs2QOJ8iustH0vSRMYdP5oYQScript configuration after the replacement
--- parameter: id_token # Obtain the JWT from the specified parameter, which corresponds to the API parameter parameterLocation: query # API in mapping mode, this parameter is optional; in pass-through mode, it is required. Specifies where the JWT is read from. Valid values: `query`,`header` bypassEmptyToken: false # Specifies whether verification is allowed to pass when the `jwt` is empty claimParameters: # claims parameter transformation. The gateway maps JWT claims to backend parameters - claimName: aud # claim name. Public and private claims are supported parameterName: aud # Name of the mapped parameter location: query # Location of the mapped parameter. Supported values: `query,header,path,formData` - claimName: scope # claim name. Public and private claims are supported parameterName: scope # Name of the mapped parameter location: query # Location of the mapped parameter. Supported values: `query,header,path,formData` - claimName: client_id # claim name. Public and private claims are supported parameterName: client_id # Name of the mapped parameter location: query # Location of the mapped parameter. Supported values: `query,header,path,formData` preventJtiReplay: false # Specifies whether to enable the anti-replay check for `jti`. Default value: false # # `Json Web Key`'s `Public Key` jwk: kty: RSA e: AQAB use: sig kid: AUTHSKEY7Ph6QS83xkN76oRwvZsJT68ejJ4PdAXmk # When only one JWK is configured, kid is optional. However, if the JWT contains a kid, the gateway verifies the consistency of the kid alg: RS256 n: i1tIYhXvfilaJi8kaIS8EpgsnDp6G4c1lEg2qRD_-1lY8jOIWAVcetq89itl7rjFJ9gmbKGBMJoutaxGHtbAkY0aINkg1_n_0NnNTZDt2UC1UNJaZh12bkYyubRLA_t6JS8PVSr5bpse1SErvDiumqU9CjxBUCd4K8R0ALxOwup6yY5gVT4Juia1bEVGPlJ-RnuMvXXbVmwuklKTiWNfBFw1lCDPftfzKVEDTXt4VphAWOT-CyZKJ8hcYiTnd_VaAYxjMQSCxmE-utrdXGhyDUaQobs0myvD2eJfzcSWG-qOTC7Hin8bvXIQ_v9BkJO3D6uoLpB14XQozWVTXaPTIw
Create the Parametric Access Control plugin
Set Plug-in Type to Parametric Access Control.
Enter the script content to implement access control. The following script implements the verification policy primarily by using condition.
The script on the right uses the evaluation of clientId and scope as an example.
condition: "$clientId = 'app_m7hfgn66xkyyxlhpkiw5kjenhy' and $scope like '%user:read:one%'"
clientId is the application ID of the M2M client.
scope is the permission scope that the M2M client has. Replace these two parameters based on your actual business requirements.
--- # # In this example, assume that the API request path is `/{userId}/...`, # API uses JWT authentication. The JWT contains a userId claim and a userType claim # The verification conditions of this plugin are as follows: # - When userType=admin, all paths are allowed # - When userType=user, only requests whose /{userId} path matches are allowed parameters: scope: "Token:scope" clientId: "Token:client_id" # # Rules are processed as follows: the conditions are evaluated in order, and based on whether the return value is `true` or `false`, the `ifTrue` logic or the `ifFalse` result is handled # `ALLOW` is immediately evaluated as a success, whereas `DENY` immediately returns an error code to the client # If neither the `ALLOW` nor the `DENY` logic is triggered, the next rule is executed rules: - name: checkScope condition: "$clientId = 'app_m7hfgn66xkyyxlhpkiw5kjenhy' and $scope like '%user:read:one%'" ifFalse: "DENY" statusCode: 403 errorMessage: "No permission by client id: ${clientId}" responseHeaders: Content-Type: application/json X-IDaaS-clientId: ${clientId} X-IDaaS-scope: ${scope} responseBody: | <Reason>No permission by client id: ${clientId}</Reason>
Bind the plugins to the API
After the two plugins are created, associate the plugins with the API operation to map the permission scope to the API operation. In this example, the association between the plugins and the API operation allows the user:read:one permission scope to control access to the hello API operation.
In the Actions column of each of the two plugins that you created, click Bind API to associate the plugin with the API operation.
Verification and usage
After you complete the preceding process, you can access the M2M server to get an authorization token. The caller uses the authorization token to access the business API operation.
Get a token
For instructions about how to obtain a token, see Authentication method: client_secret_post. In this example, perform the following operations:
Copy the Issuer URL of the M2M server.
Enter the following request parameters and send a request to the Issuer URL that you obtained.
Parameter
Description
client_secret
The application secret of the M2M client.
client_id
The application ID of the M2M client.
grant_type
A fixed value of client_credentials.
scope
The audience identifier of the M2M server followed by the permission scope. In this example, the value is
https://xxxx.aliyunidaas.com|user:read:one
API debugging
In the group details that you obtained, the second-level domain of the API group is the URL.
The request parameter is the token location and the token parameter identifier defined in the JWT plugin. In this example, the key of the request parameter is id_token and the value is the token obtained in the previous step.
The request returns the expected result, which indicates that the M2M client has permission to access the hello API operation.
References
Learn how M2M Application works.
Implement the access configuration procedure without an AccessKey by using Alibaba Cloud RAM.