OAuth2 Machine-to-Machine

The sole grant type for M2M flows. A confidential client presents its client_id and client_secret directly to the authorization server's token endpoint. The server validates the credentials and returns an access token without any user interaction. This flow is strictly for trusted, server-side applications where the client can securely store a secret.

Access tokens are minted with a specific scope parameter, limiting the permissions granted to the consuming service. For a content licensing API, scopes define granular actions:

• corpus:read for downloading training data
• license:validate for checking entitlement status
• usage:report for submitting consumption metrics This ensures a compromised service token cannot perform arbitrary operations.

M2M access tokens are typically formatted as JWT Bearer Tokens. A JWT consists of three Base64Url-encoded parts: a header specifying the signing algorithm (e.g., RS256), a payload containing registered claims like iss (issuer), sub (subject), aud (audience), and exp (expiration), and a cryptographic signature. The consumer service can locally validate the token's integrity and expiration without a network call to the authorization server.

For scenarios requiring real-time token state verification, the Token Introspection endpoint (RFC 7662) allows a resource server to query the authorization server about a token's active status. The response returns a boolean active claim and the token's metadata. This is critical for handling immediate token revocation when a licensing agreement is terminated, ensuring the resource server does not accept a token that has been administratively invalidated.

To prevent token replay attacks, OAuth2 M2M can bind an access token to a client's X.509 certificate using Mutual TLS. The token contains a cnf (confirmation) claim with the certificate's thumbprint. The resource server verifies that the client presenting the token is the same entity that established the mTLS connection. This provides hardware-backed proof of possession, far stronger than a bearer token alone.

An alternative to a shared client_secret is private_key_jwt authentication. The client generates a signed JWT assertion containing its client_id, the token endpoint URL as the audience, and an expiration timestamp. The authorization server validates the signature using the client's registered public key. This method eliminates the risk of a static secret being intercepted and is preferred for high-security, automated licensing pipelines.

A permissioning model where access tokens are granted a limited set of specific privileges rather than full account permissions. In content licensing, scopes define granular access boundaries:

• read:corpus — Retrieve training dataset metadata
• download:content — Access raw content files
• license:verify — Check entitlement status Scopes are requested during token issuance and encoded in the JWT's scope claim, enabling resource servers to enforce fine-grained authorization.