Skip to main content

Guide: M2M and API authentication

Machine to Machine Authentication​

SlashID supports the creation and management of machine to machine credentials through Oauth2 Client Credential Grants. You can leverage SlashID to implement API authentication for third party applications as well as internal services - please refer to our API docs for a complete list of endpoints.

OAuth 2.0 Client Credentials Grant​

The OAuth 2.0 client credentials grant type is intended for scoped machine-to-machine (M2M) authentication. SlashID implements an OAuth 2.0 server and exposes relevant endpoints for creating and managing clients; generating and revoking access tokens; and inspecting access tokens.

Usage​

The expected usage is summarized in the sequence diagrams below. The main actions are as follows:

  • Create scoped clients using SlashID APIs
  • Use clients to request scoped access tokens from SlashID APIs
  • Use scoped access tokens to authenticate requests to your organization's services
  • Check access tokens using SlashID APIs, including scope
  • Manage clients and tokens using SlashID APIs

M2M Auth

Creating and managing clients will be authenticated and authorized using SlashID organization IDs and corresponding API keys. The organization ID used to create a client will be stored as the client’s owner, and set as the access token’s subject during token introspection.

Client Credentials can be used to authenticate external apps. The client ID/secret pair can be used by the owner to create access tokens, which are then passed to the external app. Alternatively, the client credentials can be passed to the external app directly, which will then be able to generate its own access tokens. In general the former approach is recommended, as access tokens have a set lifetime and can be easily revoked without needing to completely disable/delete a client. Access tokens can also be scoped down to the precise requirements of the external service, in keeping with the principle of least privilege.

M2M External

One important note is that authorization checks on the resource server are still needed. A token introspection request should include both the token and the scope associated with the resources being accessed. If the scope granted to the token includes the scope in the request, the token is regarded as valid by SlashID (assuming it exists and is not revoked or expired). However, this does not guarantee that the entity that created the token (i.e., the client owner) actually has permission to access the resources. This check is internal to the service handling the API request. However, the subject and/or audience of the token can be used to identify the owner of the client and thus authorization can be performed.