M7 SSO API reference

M7 SSO is the production OAuth 2.0 and OpenID Connect authorization service for M7 applications. It signs users in, issues and refreshes credentials, supports machine application grants, and returns identity claims to registered clients.

The production API base URL and authorization-server issuer returned by discovery are:

https://sso.user.m7.org

M7 access tokens use a separate token issuer. Before configuring JWT validation, read Two issuer identifiers.

Start with OpenID Connect discovery rather than hard-coding endpoint URLs:

https://sso.user.m7.org/.well-known/openid-configuration

Use the M7 account application to manage accounts, organizations, linked identities, and OAuth applications. The M7 User API provides the related account and application-management API after sign-in.

Choose an integration

Need Use
Browser, server-rendered web app, SPA, or native app Authorization code with PKCE
Handle authorization success, cancellation, and errors Authorization callback outcomes
High-assurance browser request handoff Pushed Authorization Requests
TV, CLI, or input-constrained device Device authorization
Service-to-service access without a user client_credentials
Create an OAuth client programmatically Dynamic client registration
Account or organization management after sign-in M7 User API

For normal user sign-in, use authorization code flow with PKCE. Do not collect an M7 password in your application and do not send users directly to a form endpoint. Send the browser to /authorize; M7 chooses the appropriate sign-in and consent experience.

M7 owns the browser pages at /login, /signup, and /device_login. Do not POST to them or treat their form-processing routes as an application API.

Endpoints

Purpose Endpoint Documentation
Discovery GET /.well-known/openid-configuration Discovery and signing keys
Authorization GET /authorize Authorization requests
Pushed authorization request POST /par PAR
Token POST /token Token endpoint
Device authorization POST /device_authorization Device authorization
UserInfo GET or POST /userinfo UserInfo
Dynamic registration POST /register Registration
Token introspection POST /introspect Token lifecycle
Token revocation POST /revoke Token lifecycle
End session GET or POST /end-session Token lifecycle
Refresh-package acknowledgement POST /token/ack Token acknowledgement

Supported protocol features

  • Authorization response: code in the query response mode.
  • Grant types: authorization_code, refresh_token, client_credentials, and the OAuth device-code grant.
  • PKCE: required for authorization-code exchange; use S256.
  • Client authentication: none, client_secret_basic, client_secret_post, client_secret_jwt, and private_key_jwt, subject to the client's configured method.
  • OpenID Connect scopes: openid, profile, email, groups, and offline_access. A client may also have application-specific allowed scopes.
  • Authorization: bearer tokens are the supported public profile. The service also has compatibility handling for already provisioned DPoP-bound lineages, but does not expose a complete public RFC 9449 profile. See the project-specific authorization guide.

Important M7 extensions

M7 uses standard OAuth and OpenID Connect endpoint shapes where possible, but some token packages have additional security material:

  • User-facing token packages can include binding_chain and binding_link. Treat them like refresh-token secrets and retain them with the refresh token.
  • A refresh may use the M7 refresh_mode extension. The normal default is strict rotation. Only integrations designed for durable pending-state handling should select an acknowledgement mode.
  • /token/ack activates a pending ACK-mode replacement package. It is not a generic token endpoint.
  • /userinfo requires the requesting client_id in addition to the access token, so M7 can enforce client-token binding.
  • /jwks.json is an issuer key-discovery instruction document, not an enumerable RFC 7517 key set. Read Discovery and signing keys before wiring it into an automatic JWKS client.

Shared request rules

Use HTTPS. Token-like endpoints accept application/x-www-form-urlencoded bodies unless their page says otherwise. /register and /token/ack require JSON bodies. JSON API responses use the OAuth error shape:

{
  "error": "invalid_request",
  "error_description": "an explanation suitable for the integrator"
}

These protocol endpoints operate on one authorization transaction or credential at a time and do not use pagination.

Never log access tokens, refresh tokens, binding_chain, binding_link, client secrets, DPoP proofs, or token-ack activation secrets. Use a secure server-side store for confidential-client credentials and refresh packages.

Guides