Skip to main content
Machine clients use Machine-to-Machine (M2M) communication to interact autonomously over many types of networks (wired, wireless or cellular). An Identity Provider system authorizes machine clients enabling them to connect, exchange information and perform actions on remote resources. Machine clients can be a client application, IoT device, CLI, or a backend service that is connected either to the internet or directly to each other. Digital Identity Management leverages the OAuth 2.0 framework and Client Credentials Grant (RFC 6749) to integrate M2M applications. This grant type is an industry-standard based OAuth 2.0 protocol, used for authorization and authentication of client machines, api calls, and processes. The transmission of data and information between two M2M applications or devices is protected, and identity verification processes are handled securely. Your organization can configure the machine clients from the Admin Console with minimal effort decreasing the time to market, enabling clients to quickly onboard to connect and access the requested resources. See the Digital Identity Management Admin Guide for more details about provisioning your machine clients.

​
Machine-to-Machine Authentication/Authorization

Machines clients configured with a client credentials grant are given a secret and secret key (pair) that’s used to prove their identity. The machine client submits these credentials when requesting access to a resource such as another application or backend service. After the client machine’s successful authentication by an Identity Provider service, the client machine is granted an access token to the resource. The general M2M flow is as follows:
  • The machine client sends a request with their client ID, client secret, and grant/scope to an Identity Provider (IdP) service or authentication server.
  • Once the client machine’s credentials (identity) are successfully authenticated, the IdP service generates an access token and sends it to the client machine. The assigned role and permission(s) are encoded into the access token and define the client machine’s access level and permitted actions on the resource requested.
  • The client machine submits their access token in it’s next request to gain access to a specific resource or service.
.

​
Machine-To-Machine (M2M) Calls

M2M leverages the Digital Identity Management OIDC-based APIs and Client Credentials Grants (RFC 6749) to authorize and authenticate client machines. Digital Identity Management’s API library includes M2M APIs to facilitate communications and data exchange between the Digital Identity Management machines and clients remote systems and services. See M2M Processes for more details. Client Credentials Grant Machine applications are created and configured with a Client Credentials grant in the Admin console. The Client Credentials grant has predefined scopes that determine what resources and actions are available. Scopes allow you to grant a more granular level of access on each machine client application. Machine applications assigned with the client credentials grant use token(s) to access a system’s resources and services (not user’s resources) as an authorized application with the correct privileges. When creating a machine application, only the Client Credentials Grant and machine-to-machine (m2m) scopes are available for assignment. Machine-to-machine APIs The machine clients are provisioned/verified with their user attributes such as name and value. Machine clients cannot impersonate user identities, and can only access resources with the correct token (authorization/authentication) and privileges. Digital Identity Management M2M APIs don’t require a user context, and incorporate access tokens for authentication within the OIDC framework. Digital Identity Management allow customers to manage Digital Identity Management entities, and synchronize them with customer information in their own systems. See the following Digital Identity Management Activation APIs used for machine clients. Note: The machine client’s history or activities are retrievable from the Care console for viewing. Use Case Examples An example is when a backend system needs to get a user’s profile information, the backend system (machine application) is granted access to the service via a token, and calls the appropriate API to get user profile information for a particular user. Parent topic:Digital Identity Management Features