Compatibility Differences and Current Gaps

M7 exposes a mostly compatible OAuth 2.0 and OpenID Connect surface, but it is not intended to be a drop-in implementation of every ecosystem convention.

The main reason is M7's Assume Breach security posture. When a standard leaves room for operational choice, M7 may prefer issuer-controlled recovery, narrower key exposure, stronger client binding, and lower blast radius over broad compatibility shortcuts.

Use this page as the public summary of the current differences that matter during integration. The endpoint-specific pages remain the source of truth for exact request and response shapes.

Certificate and key handling

The biggest compatibility difference today is certificate and signing-key handling.

  • /jwks.json does not publish a traditional enumerable JWKS inventory.
  • Instead, it returns issuer-managed lookup instructions for resolving a specific key by kid.
  • This behavior is intentional and tied to the Assume Breach model.
  • If your JWT or OIDC library expects one static JWKS document containing every active signing key, you will likely need a small adapter or cache layer.

Related current behavior:

  • Tokens returned from this surface are currently issued with iss values from id.m7.org.
  • The SSO discovery documents still describe the sso.user.m7.org integration surface, so verify issuer handling carefully against the current deployment behavior.

Endpoint-specific differences

The following public endpoints currently have M7-specific behavior that integrators should review before assuming generic OAuth or OIDC defaults:

  • /token: the refresh flow currently uses token=<REFRESH_TOKEN> plus binding_chain and binding_link.
  • /userinfo: client_id is currently required, and the token must belong to that same client.
  • /register: the public registration surface is bearer-protected and create-only.
  • /introspect: the current introspection endpoint is for confidential clients only.
  • /end-session: RP-specific post-logout return handling depends on client_id or a valid id_token_hint.
  • /jwks.json: key discovery is per-kid rather than a full keyset listing.

Public routes that are not stable third-party integration endpoints

The following public routes exist as part of the hosted browser flow, but they should currently be treated as implementation details rather than stable third-party API endpoints:

  • /login-init
  • /authorize-process
  • /process-login
  • /process-signup
  • /device_login_process
  • /end-session-process

These routes may be visible during hosted M7 flows, but they are not part of the public compatibility promise at this time.

Features not currently exposed as a public compatibility surface

The following capabilities are not currently published as part of the public-facing compatibility contract:

  • a traditional enumerable JWKS endpoint
  • registration management endpoints for reading, updating, or deleting a registered client
  • registration_access_token
  • registration_client_uri
  • public-client access to the current introspection endpoint

Integration guidance

If your client, SDK, gateway, or identity broker assumes strict default OAuth or OIDC provider behavior, review this page before you begin integration.

In practice, teams should pay closest attention to:

  • issuer validation
  • key resolution and JWK caching strategy
  • refresh-token storage, including binding_chain and binding_link
  • whether their library assumes self-service dynamic client-registration management

This page will expand as the public compatibility surface is documented in more detail.