Machine-to-machine (M2M) permission management is a method for authorizing applications to interact without user involvement. IDaaS grants authorization, and gateway products perform authentication. This process controls how calling applications access protected resources and prevents unauthorized access.
Scenarios
In digital collaboration scenarios, when you expose business system capabilities to third-party partners, such as outsourced teams, you must establish an automated authorization mechanism based on machine identities. During implementation, you can use the following solutions:
Establish a partner admission authentication system: Use methods, such as pre-shared keys or the OAuth 2.0 client credentials flow, to assign an independent machine identity to each partner.
Adopt a fine-grained permission management policy: At the API access control level, bind the access permissions for non-core business data interfaces to specific partner identities. For example, you can configure the system to allow only a specific development team to call data visualization-related API services.
This authorization model, based on M2M communication, ensures efficient interaction between automated systems. It also reduces data security risks through identity authentication and permission isolation mechanisms. This model is especially suitable for system integration scenarios that do not require end-user intervention, such as development collaboration and data dashboard construction.
To use the M2M application (machine-to-machine permission management) feature, you must create an EIAM instance (free or paid). Each instance includes a free trial of two M2M applications. If you have not activated the service, go to Purchase and Activate.
Feature overview
Machine-to-machine (M2M) permission management is a method for authorizing applications to interact without user involvement. IDaaS grants authorization, and gateway products perform authentication. This process controls how calling applications access protected resources and prevents unauthorized access.
Typical scenarios
An enterprise exposes internal APIs for external systems, such as outsourced or supplier systems, to call. The enterprise must implement fine-grained control over the calling permissions.
An enterprise accesses cloud provider resources from a non-cloud environment, such as a multicloud environment.
Typical customers
Customers who need to expose APIs externally using API Gateway.
All customers who need to access Alibaba Cloud without an AccessKey (AK), and multicloud customers. The IDaaS solution extends the Alibaba Cloud AK-free solution to cover local development environments and multicloud scenarios.
Core features
Credential management: Manage credentials for calling applications in IDaaS. These credentials are used to request an
Access Tokenfrom IDaaS.Authorization management: Define calling applications and authorize them.
Pre-integrated gateways: Integrate with API Gateway to perform authentication in unified application authentication scenarios.
Terms
Term | Description |
M2M application (Machine-to-Machine) | An application used for machine-to-machine permission management. The authorization and authentication processes do not require user interaction. It can integrate with API Gateway to implement API permission control and with Resource Access Management (RAM) to enable AK-free access. Note An M2M application can act as both a client and a server. |
Client | The calling application (corresponding to a Client in OAuth). It is an application that initiates access to a protected resource. |
Server | The called application or protected resource (corresponding to a Resource Server in OAuth). It represents an external resource entity. |
Audience identifier | Corresponds to the aud claim, which indicates the audience of the Access Token. This is the unique identifier of the server. It cannot be modified after it is entered. |
Configuration flow
This topic describes the configuration flow, focusing on API Gateway. An M2M application can act as a calling entity (a Client) or a called entity (a Resource Server).
Use an M2M application for only one of these roles.
Call flow
The calling application authenticates its identity and requests an
Access Token.IDaaS returns an
Access Tokenthat contains permission information.The calling application uses the
Access Tokento access the called application.The called application, API Gateway, or Security Token Service (STS) verifies the validity of the
Token.The called application, API Gateway, or STS performs authorization and then allows or denies the operation.
A response is returned.
Application configuration
Add an application
Log on to the IDaaS console. Then, select and open your IDaaS instance to go to its management console.
Choose , and click Add Application.
In the dialog box that appears, enter an application name in the Application Name field and click Add Now. The system automatically redirects you to the M2M application details page.
General
Basic Information.
ID: A unique identifier automatically generated by the system to identify the M2M application.
Application Name: A custom name used to distinguish different M2M applications in the management interface.
Credential Management. M2M applications support multiple Credential Type.
Client Secret Credential. You can click Add client_secret to generate a client credential. The client uses this credential for identity verification and authorization requests when calling server APIs.
Client_id: The unique identifier of the M2M application, used for authentication during interactions with the identity service.
client_secret: The key for the M2M application, used for permission verification during interactions with the identity service.
View: Click to display the full content of the client_secret.
Delete: Delete the current client_secret. After deletion, you must add a new key.
Specify Validity Period: Configure the validity period of the client_secret. After it expires, you must generate a new key.
NoteKeep the client_secret secure. If it is compromised, immediately delete the old key and add a new one to ensure security.
Certificates Credential. On the Certificates Credential tab, click Manually Add to go to the credential creation page.
Scenario Type: The default is PRIVATE_KEY_JWT authentication.
Encryption Type: The default is RSA-2048.
Public Key: Paste the public key content into the text box. Ensure the public key format starts with
-----BEGIN PUBLIC KEY-----and ends with-----END PUBLIC KEY-----. An incorrect format will cause verification to fail.
For more information about how to configure PCA, OpenID Connect (OIDC), and PKCS#7 credential types, see Create a federated credential.
Limits on Network Zone. You can use the Client Network Zone configuration to restrict the access sources of the M2M application.
All: Allows calls to the M2M application from any IP address.
Specific Network Zone: Allows calls only from specific IP addresses or IP address ranges. You must select an existing network scope from the drop-down list.
Application Settings. The OAuth 2.0-related configuration for the M2M application includes the following information.
Issuer: A unique identifier that indicates the source of the issued token. It serves as the base URI for OAuth 2.0-related APIs and ensures that the token source is traceable and unique during authentication.
OIDC Discovery Endpoint: A publicly accessible endpoint used to obtain information about the OIDC protocol endpoints, authentication modes, and parameter specifications supported by the current identity service.
OAuth2 Discovery Endpoint: A publicly accessible endpoint that provides information about the OAuth 2.0 authorization endpoints and authorization modes that the current IDaaS supports. This helps developers correctly configure the OAuth 2.0 flow.
Token Endpoint: The API endpoint for requesting and obtaining an OAuth 2.0 token. It supports issuing identity credentials through modes such as authorization code and client credentials.
Public Key Verification Endpoint: An API that provides public key information for verifying token signatures. It supports a dynamic public key rotation mechanism to ensure timely and secure token verification and prevent tampering during the single sign-on (SSO) process.
Server Permission Control
After you enable server-side permission granting, the M2M application acts as the called party (the resource server in OAuth 2.0). You can configure permissions and authorize callers to achieve fine-grained control over their permissions.
When you enable this feature for the first time, you must add an audience identifier. The audience identifier corresponds to the aud claim, which indicates the audience of the Access Token. This identifier specifies the service that holds the protected resources. The identifier cannot be modified after it is added.
Apply for permissions.
ResourceServer Identifier: Corresponds to the
audclaim, which indicates the audience of the Access Token. This is the service that holds the protected resources.Server Permission Control: Click the toggle to enable this feature. In the Enable Permission Granting dialog box, enter the endpoint of the protected resource in the Audience Identifier text box. This must correspond to the
audclaim in OAuth 2.0, which is the address of the resource server that the client application calls.Custom Principal: After you enable custom subjects, the subject of the issued Access Token changes from client_id to <client_id>:<client.activeSubjectUrn>. The
client.activeSubjectUrnis set in the attribute mapping of the application's federated credential.
Permission management. After you enable , you can add permissions for or remove permissions from the calling application.
Click the Create Scope button. On the Add Permission page, enter the following information:
Scope Type: Select Machines Scope (for machine-to-machine call scenarios).
Scope Name: Enter the display name for the permission, such as "User Read Permission". This name appears in the management console.
Scope Value: Enter the unique identifier for the permission. Use the resource:operation:condition format, such as
user:read:all. This identifier must be unique within the application.
NoteResource: The specific object being operated on, such as a user, role, file, or API. For example, user represents a user resource, and file represents a file resource.
Operation: The specific action performed on the resource, such as read, write, or delete. For example, read represents a read operation, and write represents a write operation.
Condition: The scope or constraint of the operation, such as range, time, or permission level. For example, all represents all users, and admin represents administrator permissions.
Authorized applications. In the Authorized Applications list, you can view or manage the applications that are authorized to call this resource server and their assigned permissions, such as by granting or revoking permissions.
Client Permission Management
Click to view the permissions that have been granted to this application. Permissions are added and granted in the section of the called application (resource server).