All Products
Search

This Product

    Identity as a Service:M2M applications

    Document Center

    Identity as a Service:M2M applications

    Last Updated:Jun 04, 2026

    M2M permission management authorizes application-to-application access without user involvement. IDaaS handles authorization while gateway products handle authentication, controlling access to protected resources.

    Scenarios

    When exposing business APIs to third-party partners such as outsourced teams, establish an automated authorization mechanism based on machine identities:

    • Establish a partner admission authentication system: Use pre-shared keys or the OAuth 2.0 client credentials flow to assign each partner an independent machine identity.

    • Adopt a fine-grained permission management policy: Bind API-level access permissions to specific partner identities. For example, allow only a specific team to call data visualization APIs.

    This M2M authorization model ensures efficient automated system interaction while reducing security risks through identity authentication and permission isolation. It suits integration scenarios without end-user intervention, such as development collaboration and data dashboard construction.

    Note

    To use M2M applications, 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

    M2M permission management authorizes application-to-application access without user involvement. IDaaS handles authorization while gateway products perform authentication to control access to protected resources.

    Typical scenarios

    • An enterprise exposes internal APIs to external systems (outsourced or supplier) and requires fine-grained permission control.

    • An enterprise accesses cloud resources from non-cloud or multicloud environments.

    Typical customers

    • Customers who expose APIs externally through API Gateway.

    • Customers who access Alibaba Cloud without an AccessKey (AK), including multicloud users. IDaaS extends AK-free access to local development and multicloud environments.

    Core features

    • Credential management: Manage calling application credentials used to request an Access Token from IDaaS.

    • Authorization management: Define calling applications and authorize them.

    • Pre-integrated gateways: Integrate with API Gateway for unified application authentication.

    Terms

    Term

    Description

    M2M application (Machine-to-Machine)

    An application for machine-to-machine permission management without user interaction. Integrates with API Gateway for API permission control and with RAM for AK-free access.

    Note

    An M2M application can act as both a client and a server.

    Client

    The calling application (Client in OAuth) that initiates access to a protected resource.

    Server

    The called application or protected resource (Resource Server in OAuth). It represents an external resource entity.

    Audience identifier

    Unique server identifier corresponding to the aud claim in the Access Token. Cannot be modified after entry.

    Configuration flow

    The following configuration flow focuses on API Gateway. An M2M application can act as a Client (calling entity) or a Resource Server (called entity).

    Note

    Use an M2M application for only one of these roles.

    Call flow

    1. The calling application authenticates its identity and requests an Access Token.

    2. IDaaS returns an Access Token that contains permission information.

    3. The calling application uses the Access Token to access the called application.

    4. The called application, API Gateway, or Security Token Service (STS) verifies the validity of the Token.

    5. The called application, API Gateway, or STS performs authorization and then allows or denies the operation.

    6. A response is returned.

    Application configuration

    Add an application

    1. Log on to the IDaaS console, and open your IDaaS instance.

    2. Choose Application > M2M Application, and click Add Application.

    3. In the dialog box that appears, enter an application name in the Application Name field and click Add. The system automatically redirects you to the M2M application details page.

    General

    1. Basic Information.

      • ID: System-generated unique identifier for the M2M application.

      • Application Name: A custom name to distinguish M2M applications in the console.

    2. Certificate Management. M2M applications support multiple Authentication Type.

      1. Client Secret Credential. Click Add client_secret to generate a client credential for identity verification and authorization when calling server APIs.

        • Client_id: Unique identifier of the M2M application for authentication with the identity service.

        • client_secret: Secret key for the M2M application, used for permission verification during interactions with the identity service.

          • View: Displays the full client_secret.

          • Delete: Deletes the current client_secret. You must then add a new key.

          • Specify Validity Period: Sets the client_secret expiration. Generate a new key after expiry.

        Note

        Keep the client_secret secure. If compromised, immediately delete and replace it.

      2. 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. It must start with -----BEGIN PUBLIC KEY----- and end with -----END PUBLIC KEY-----. An incorrect format will cause verification to fail.

      3. For more information about how to configure PCA, OpenID Connect (OIDC), and PKCS#7 credential types, see Create a federated credential.

    3. Limits on Network Zone. Use Client Network Zone to restrict access sources for the M2M application.

      • All: Allows calls to the M2M application from any IP address.

      • Specific Network Zone: Allows calls only from specified IP addresses or ranges. Select an existing network scope from the drop-down list.

    4. Application Settings. OAuth 2.0 configuration for the M2M application:

      • Issuer: Unique identifier of the token issuer. Serves as the base URI for OAuth 2.0 APIs.

      • OIDC Discovery Endpoint: Public endpoint providing OIDC protocol endpoints, authentication modes, and parameter specifications for the identity service.

      • OAuth2 Discovery Endpoint: Public endpoint listing OAuth 2.0 authorization endpoints and modes supported by IDaaS.

      • Token Endpoint: API endpoint for requesting OAuth 2.0 tokens. Supports authorization code and client credentials modes.

      • Public Key Endpoint: API providing public keys for token signature verification. Supports dynamic key rotation for secure SSO.

    Server Permission Control

    When enabled, the M2M application acts as the resource server (called party in OAuth 2.0). Configure permissions and authorize callers for fine-grained access control.

    Note

    On first enablement, add an audience identifier (the aud claim in the Access Token) that specifies the service holding the protected resources. This identifier cannot be modified after it is added.

    1. Apply for permissions.

      • ResourceServer Identifier: The aud claim identifying the service that holds the protected resources.

      • Server Permission Control: Toggle to enable. In the Enable Permission Control dialog box, enter the protected resource endpoint as the Audience Identifier. This corresponds to the aud claim in OAuth 2.0, the resource server address that the client calls.

      • Custom Principal: When enabled, the Access Token subject changes from client_id to <client_id>:<client.activeSubjectUrn>. Set client.activeSubjectUrn in the federated credential attribute mapping.

    2. Manage permissions. After enabling Server Permission Control, add or remove permissions for calling applications.

      Click Create Scope and enter the following information:

      • Scope Type: Select Machines Scope (for machine-to-machine call scenarios).

      • Scope Name: Enter a display name, such as "User Read Permission".

      • Scope Value: Enter a unique identifier in resource:operation:condition format, such as user:read:all.

      Note

      • Resource: The object being operated on (user, role, file, API).

      • Operation: The action on the resource (read, write, delete).

      • Condition: The scope or constraint (all, admin, specific range).

    3. View and manage authorized calling applications and their permissions in the Authorized Applications list.

    Client Permission Management

    Click Client Permission Management to view permissions granted to this application. Permissions are managed in the Server Permission Control section of the called application (resource server).

    Related best practices