M7 provider capability card

Connect to M7 Identity

Issuer: https://sso.user.m7.org

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

Live discovery supplies endpoint locations and advertised capabilities. Use the provider profile for the integration contract and current testing status.

Response-encryption evidence was updated on 2026-09-16. See registered response encryption for the contract and the distinction between scoped live acceptance and the wider test matrix.

Status: Release-candidate summary
Derived from: M7 OAuth 2.0 and OpenID Connect Provider Profile
Last reviewed: 2026-09-20

This is the short compatibility card for the M7 authorization server. The provider profile is normative; live discovery is authoritative for endpoints and currently advertised feature sets.

Category Capability Status
Discovery OpenID Connect and OAuth authorization-server metadata Supported
Browser authorization Authorization code with mandatory PKCE S256 Supported
Plain authorization responses query, form_post, fragment Supported, advertised and live-tested
Signed authorization responses query.jwt, form_post.jwt, fragment.jwt, jwt; RS256/RS512 JARM Signing and encryption deployed; encrypted form_post.jwt passed scoped live acceptance
Web Message responses web_message.opener, web_message.parent, web_message Supported and advertised; popup and approved-origin iframe live checks passed
Back-channel authorization PAR with HTTP 201 response Supported
Signed authorization requests JAR by value or registered HTTPS URI; RS256, RS384, RS512, ES256 Supported at /authorize; per-client opt-in
Consumer email sign-in Magic link and one-time code in one message; original-browser confirmation and optional email 2FA Supported; email sign-in
Consumer two-factor authentication Independent TOTP checks for password login, email sign-in, Device Code approval, and account/session reuse; recovery codes and unlink options Supported; user-configurable behavior
Device sign-in OAuth Device Authorization Grant Supported
Machine access client_credentials for confidential clients Supported
Delegated service access RFC 8693 local-user, single-target Token Exchange at /token Deployed and advertised; consumer exchange, offline refresh and permission withdrawal live-tested; contract and limits
Access-token client identity Requester in client_id; receiving app in issuer-owned m7.target_client_id; resource audience plus target UUID in aud Implemented; ordinary machine/user issuance and delegated consumer refresh live-tested; claim semantics
Refresh Rotating user refresh-token lineage Supported
Public clients none authentication with PKCE and revocation Supported
Secret authentication Basic, POST, and HMAC JWT (HS256/384/512) Supported
Asymmetric authentication Private-key JWT (RS256/384/512, ES256) Supported
ID tokens 18 signing profiles: 15 asymmetric plus HS256/384/512 Issuance accepted; all 18 profiles deployed and advertised, verified from both discovery URLs
HMAC token signing HS256/384/512 for confidential clients with a recoverable client secret Client credentials, device/strict refresh and browser login/profile/refresh accepted; none eligibility restriction locally tested, deployment verification pending; setup and advertisement
Personal signing keys Separate access/refresh lineage keys for all 15 asymmetric profiles Device issuance and strict refresh live-tested
M7 Identity SDK 15 asymmetric profiles with explicit allowlist and compatible key resolution Updated source accepted; additional profiles require m7crypto; stable downloads unchanged
Post-quantum browser sessions ML-DSA with the current Web SDK token cookies Not ready; cookie/storage redesign required; device/native crypto paths accepted
UserInfo JSON, signed RS256, or signed RS512 Supported
Outbound response encryption ID tokens, JARM and signed UserInfo; RSA-OAEP-256 / A256GCM Deployed and advertised; inline-key RS256 PHP login, UserInfo, strict refresh and cancellation passed; broader live matrix remains separate
PHP encrypted-response receiver token-php 0.1.3-rc.1 and web-php 0.1.4-rc.1 with the required native crypto runtime Local candidate ZIPs built and verified; scoped live web-candidate acceptance; stable downloads do not include JWE; installation and limits
Sender constraint RFC 9449 DPoP using ES256 Supported and advertised
Token state Confidential-client introspection Supported
Revocation Public and confidential client revocation with opaque HTTP 200 response Supported
Logout RP-initiated end-session flow with exact registered return URI Supported
Front-channel logout Browser iframe notifications with iss and stable root sid Deployed and advertised; explicit end-session and chooser logout accepted
Back-channel logout Signed, optionally encrypted Logout Token POST with stable root sid Deployed and advertised; receiver acknowledgement does not guarantee local invalidation
Account session revocation Revoke a root login and its token family, then notify participating apps by back channel Supported through User API session management
Web/PHP logout receiver Browser cookie clearing; verified back-channel receipt Current installed source; back-channel application-session invalidation remains separate SDK work
Registration Authenticated Dynamic Client Registration Supported; resource audience assignment remains administrative
Rate limiting OAuth 429 response with Retry-After and rolling quiet-period recovery Supported
Mutual TLS RFC 8705 tls_client_auth, self_signed_tls_client_auth, dedicated endpoint aliases, and certificate-bound tokens Supported and advertised
OpenID certification Official conformance-suite result Pending; no certification claim

The RC6 provider profile lists every algorithm. Third-party integrations need support for the exact selected algorithm and key type. At 2026-09-15 21:49:24 UTC, both live metadata documents returned identical metadata advertising all 18 ID-token profiles, including HS256, HS384 and HS512. Public JWKS covered all 15 asymmetric profiles and contained no symmetric material. HMAC has no public key entry. Follow the verified discovery contract and live discovery when selecting algorithms.

Both discovery documents also advertise all ten response modes and JARM RS256/RS512 signing, verified at 2026-09-15 06:24 UTC. Each mode passed direct authorization, PAR and cancellation. Flexible web_message passed in both popup and iframe form. Iframe use requires provider-approved origins; fresh password sign-in passed, while remembered-session reuse and iframe MFA, email, federation and consent denial were not established by those checks. See response modes for client configuration and browser requirements. Updated SDK source supports these modes; existing downloads were not rebuilt for this increment.

Both live discovery documents advertised all four logout support/session-support flags as true at 2026-09-20 02:58:25 UTC. Notifications follow explicit logout or session revocation; ordinary account switching sends none. Both channels always include sid. See logout notifications for application registration, participation, delivery limits and the current SDK boundary.

Intentionally outside the current profile

  • implicit and hybrid flows;
  • PKCE plain;
  • JAR submitted to /par or configured through Dynamic Registration;
  • encrypted Request Objects;
  • external-token exchange (out of scope), impersonation, multiple exchange targets and chained exchanges (deferred);
  • DPoP nonces;
  • public-client introspection; and
  • automatic Dynamic Registration authority packs.

For exact statuses, response shapes, algorithms, audience rules, DPoP challenges, and release limitations, use the full provider profile.