M7 Identity Platform overview

M7 Identity platform.

People and friendly robots collaborate in a bright seminar studio around a connected wall of colorful platform modules.

M7 Identity is a general-purpose identity provider built on OAuth 2.0 and OpenID Connect. It gives your applications a common way to sign people in, identify services, and control access to APIs. Security controls cover sign-in requests, application authentication, and the life of each credential. Optional M7 extensions add further control over credential renewal and binding.

Sign up Get the SDK
Back to top

Sign-in and API access

OpenID Connect tells your application who signed in. OAuth gives an application limited permission to use an API, either on a person's behalf or as a service acting for itself. Together, they provide a standard foundation for login, connected applications, and automated work.

Browser sign-in uses authorization code flow with PKCE, which helps protect authorization codes from misuse. Your application receives signed identity information that it can verify to recognize the person who signed in.

For command-line tools and devices with limited input, the Device Authorization Grant lets a person approve access through a browser. These flows give you a choice of sign-in experience while keeping identity handling consistent.

Services, background jobs, and AI agents can use client credentials to obtain access under an application's own identity. Each application receives the API access allowed by its registration. This gives automated work a distinct identity and a defined set of permissions.

M7 also manages API keys for people and organizations. Create, activate, rotate and revoke keys, and set expiry dates, use limits and IP restrictions. Receiving APIs can ask M7 to check a key’s owner, audience and scopes before applying their own access rules. API keys are separate credentials from OAuth access tokens.

Back to top

Organizations and permissions

An audience identifies the API a token is intended for. Scopes describe the access it grants. M7 limits both to what the application is allowed to receive.

For organization members, identity responses can also include organization and group information when the appropriate scope is granted. Your application uses that information, along with validated tokens and its own access rules, to decide what each person or service can do.

Back to top

Security and credential control

M7 requires PKCE and exact registered HTTPS return addresses for authorization-code sign-in. Applications can authenticate with client secrets, signed assertions, or mutual TLS, according to their registration.

For additional protection, pushed authorization requests (PAR) send request details directly to M7. Signed authorization requests (JAR) protect those details against alteration. DPoP and certificate-bound tokens require proof of the associated key or certificate when the token is used, helping prevent reuse of a stolen token by itself.

Refresh tokens let approved applications renew user access. M7 replaces the refresh credential after each successful renewal. Applications can revoke their credentials when access is no longer needed. Confidential clients can check the current state of tokens issued to them through introspection. Applications can also initiate sign-out and return people to a registered address.

Back to top

Integration and M7 extensions

Discovery documents publish the current endpoints and advertised capabilities. Published signing keys let compatible libraries verify identity responses. Authenticated Dynamic Client Registration supports automated application setup, with API audience access assigned by an administrator.

Use a compatible OAuth or OpenID Connect library, or the M7 Identity SDK. Start with the integration quickstart, then consult the capability card for a compact compatibility checklist.

M7 adds binding information and an optional acknowledgement step to credential renewal for integrations that need them. These extensions support additional control over the renewal process. Standard integrations can use the base refresh flow under the default binding policy; applications that select a stricter policy follow its additional requirements.

The current provider profile is a release candidate. Independent-library, mutual-TLS, and scoped signed-request interoperability testing has passed. Official OpenID conformance testing remains pending.