# M7 provider capability card ## Connect to M7 Identity Issuer: Discovery JSON: - [Discovery and signing keys](https://m7.org/docs/api/sso.user.m7.org/discovery-and-keys.md) - [Integration quickstart](https://m7.org/docs/api/sso.user.m7.org/quickstart.md) - [Provider profile](https://m7.org/docs/api/sso.user.m7.org/provider-profile.md) - [M7 Identity SDK and current downloads](https://m7.org/docs/sdk/m7-identity/) 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](https://m7.org/docs/api/sso.user.m7.org/response-encryption.md) 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](https://m7.org/docs/api/sso.user.m7.org/provider-profile.md)\ 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](https://m7.org/docs/api/sso.user.m7.org/email-sign-in.md) | | 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](https://m7.org/docs/api/sso.user.m7.org/two-factor-authentication.md) | | 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](https://m7.org/docs/api/sso.user.m7.org/token.md#token-exchange-rfc-8693) | | 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](https://m7.org/docs/api/sso.user.m7.org/token-formats.md#requesting-client-and-receiving-application) | | 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](https://m7.org/docs/api/sso.user.m7.org/registration.md#hmac-token-signing) and [advertisement](https://m7.org/docs/api/sso.user.m7.org/discovery-and-keys.md#hmac-and-discovery) | | 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](https://m7.org/docs/api/sso.user.m7.org/discovery-and-keys.md#post-quantum-tokens-and-browser-storage); 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](https://m7.org/docs/sdk/m7-identity/response-encryption) | | 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](https://m7.org/docs/api/api.user.m7.org/sessions) | | 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](https://m7.org/docs/api/sso.user.m7.org/provider-profile.md#signing-algorithm-selection) 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](https://m7.org/docs/api/sso.user.m7.org/discovery-and-keys.md#hmac-and-discovery) 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](https://m7.org/docs/api/sso.user.m7.org/response-modes.md) 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](https://m7.org/docs/api/sso.user.m7.org/logout-notifications.md) 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](https://m7.org/docs/api/sso.user.m7.org/provider-profile.md).