Machine-to-machine permission management (M2M) is application-to-application authorization that does not require user involvement. IDaaS performs the authorization and works with gateway-type products to perform authentication, thereby controlling how calling applications access protected resources and preventing unauthorized access.
Use cases
In digital collaboration scenarios, when an enterprise needs to expose some of its business system capabilities to third-party partners (such as outsourced teams), it typically needs to establish an automated authorization mechanism based on machine identities. During implementation, the enterprise can adopt the following solutions:
Establish a partner admission authentication system: Use technical means such as pre-shared keys or the OAuth 2.0 client credentials flow to assign a unique machine identity to each partner.
Adopt fine-grained permission management policies: At the API access control layer, bind the access permissions of non-core business data APIs to specific partner identities. For example, you can allow only a specific development team to call data visualization-related API services.
This authorization model based on M2M (machine-to-machine) communication ensures efficient interaction between automated systems while reducing data security risks through identity authentication and permission isolation mechanisms. It is especially suitable for system integration scenarios that do not require end-user involvement, 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 (a free instance or a paid instance). Each instance comes with a quota of 2 M2M applications for a free trial. If you have not activated the service, go to activate and purchase.
Feature overview
Machine-to-machine permission management (M2M) is application-to-application authorization that does not require user involvement. IDaaS performs the authorization and works with gateway-type products to perform authentication, thereby controlling how calling applications access protected resources and preventing unauthorized access.
Typical scenarios
An enterprise exposes internal APIs to outsourcing or vendor systems and needs fine-grained control over their calling permissions.
An enterprise accesses cloud provider resources from a non-cloud provider environment (such as a multi-cloud environment).
Typical customers
Customers who need to expose APIs externally by using API Gateway.
All customers who require AccessKey-free access to Alibaba Cloud, as well as multi-cloud customers. The IDaaS solution builds on the Alibaba Cloud AccessKey-free solution and additionally covers on-premises development environments and multi-cloud environments.
Core features
Credential management: Manages the credentials of calling applications in IDaaS, which are used to request
Access Token.Authorization management: Defines calling applications and grants permissions to them.
Pre-integrated gateway: Works with API Gateway to perform authentication in unified application authentication scenarios.
Basic concepts
Concept | Description |
M2M application (Machine-to-Machine) | An application used for machine-to-machine permission management. The authorization and authentication processes do not require user involvement. It can work with API Gateway to implement API permission control and with RAM to implement AccessKey-free access. Note An M2M application can act as either a client or a server. |
Client | : The calling application (corresponds to Client in OAuth). It is an application that initiates access to protected resources. |
Server | : The called application or protected resource (corresponds to Resource Server in OAuth). It represents an external resource entity. |
Audience | corresponds to the aud claim and indicates the audience of the Access Token, which is the unique identifier of the server. It cannot be modified after it is entered. |
Configuration process
This topic mainly describes the configuration process of API Gateway. An M2M application can act as the caller (Client) or as the callee (Resource Server).
We recommend that each M2M application use only one of these roles.
Call process
The calling application verifies its identity and requests
Access Token.IDaaS returns
Access Token(which contains permission information).The calling application carries
Access Tokento access the called application.The called application (or API Gateway or the STS service) verifies whether
Tokenis valid.The called application (or API Gateway or the STS service) performs authentication and allows or blocks the operation.
The response is returned.
Application configuration
Add an application
Log on to the IDaaS console, select and open your IDaaS instance, and then go to the console of that instance.
Choose , and then click Add Application.
In the dialog box that appears, enter your application name in the Application Name field, and then click Add Now. The system automatically redirects you to the M2M application details configuration page.
General
Basic Information.
ID: The unique identifier that is automatically generated by the system and used to uniquely identify the M2M application.
Application Name: A custom value that is used to distinguish different M2M applications in the management console.
Certificate Management. An M2M application supports multiple Authentication 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 it calls server-side APIs.
client_id: The unique identifier of the M2M application, which is used for identity verification when interacting with the application identity service.
client_secret: The secret of the M2M application, which is used for permission verification when interacting with the application identity service.
View: Click to view the full content of client_secret.
Delete: Delete the current client_secret. After it is deleted, you must add a new secret.
Specify Validity Period: Configure the validity period of client_secret. After the validity period expires, you must generate a new secret.
NoteKeep client_secret confidential. If it is leaked, immediately delete the old secret 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 value is PRIVATE_KEY_JWT authentication.
Encryption Type: The default value is RSA-2048.
Public Key: Paste the public key content in the text box. Make sure that the public key format starts with
-----BEGIN PUBLIC KEY-----and ends with-----END PUBLIC KEY-----. An incorrect format causes verification to fail.
For information about how to configure the PCA, OIDC, and PKCS#7 credential types, see Create a federated credential.
Limits on Network Zone. By using the Client Network Zone configuration, you can 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, from the Network Range drop-down list, a network range that has already been added and allowed for access.
Application Settings. The OAuth2-related configuration of the M2M application contains the following key information.
Issuer: The unique identifier of the Token issuer. It serves as the BaseUrl of OAuth2-related APIs and ensures that the Token source is traceable and unique during the authentication process.
OIDC Discovery Endpoint: A publicly accessible endpoint that is used to obtain the OIDC protocol endpoint information, authentication modes, and parameter specifications supported by the current identity service.
OAuth2 Discovery Endpoint: A publicly accessible endpoint that provides the OAuth2 authorization endpoint information and authorization modes supported by the current IDaaS instance. It provides developers with a compliance basis for configuring the OAuth2 flow.
Token Endpoint: The API address that is used to request and obtain an OAuth2 Token. It supports issuing identity credentials through modes such as authorization code and client credentials.
Public Key Verification Endpoint: An API that provides the public key information used to verify Token signatures. It supports dynamic public key rotation, which ensures the timeliness and tamper-proof security of Token verification in the SSO process.
Server Permission Control
After you enable server-side permission exposure, the M2M application acts as the callee (the resource server in OAuth). You can configure permissions and grant them to callers to implement fine-grained control over caller permissions.
When you enable this feature for the first time, you must add an audience. The audience corresponds to the aud claim and identifies the audience of the Access Token, which is the service that holds the protected resources. It cannot be modified after it is added.
Permission application.
ResourceServer Identifier: Corresponds to the aud claim and identifies the audience of the Access Token, which is the service that holds the protected resources.
Server Permission Control: Click the enable button, and then, in the Enable Permission Exposure dialog box, in the Audience field, enter the caller's protected resource service address (which must correspond to the aud claim in OAuth, that is, the resource server address of the calling application).
Custom Principal: After you enable a custom subject, the issued Access Token changes from (clientld) to <clientld>:<client.activeSubjectUrn>, where client.activeSubjectUrn is configured in the attribute mapping of the federated credential of the application.
Permission management. After you enable , you can add or remove permissions for calling applications.
Click Create Scope and then configure the following key information on the Add Permission page:
Scope Type: Select Machines Scope (applicable to machine-to-machine call scenarios).
Scope Name: Enter the display name of the permission in the management console (for example, "User Read Permission").
Scope Value: Enter the unique identifier of the permission. We recommend that you use the "resource:action:condition" format, such as
user:read:all, and make sure that the identifier is unique within the application.
NoteResource: the specific object on which an operation is performed, such as a user, role, file, or API. Examples: user indicates the user resource; file indicates the file resource.
Action: the specific behavior performed on a resource, such as read, write, or delete. Examples: read indicates the read operation; write indicates the write operation.
Condition: the scope or constraints of an operation, such as scope, time, or permission level. Examples: all indicates all users; admin indicates administrator permissions.
Authorize applications. In the Authorized Applications list, you can view or manage the permissions of called applications, such as granting or revoking permissions.
Client Permission Management
Click to view the permissions that are granted to the application. In of the called application, you can add permissions and grant authorization.