Choose the security profile your app can use

Suppose you run a small PHP booking site. People sign in with M7 Identity, and your site calls a protected API to manage their appointments. You need a security configuration your browser, server and API can actually carry through.

The earlier Stock OIDC and the M7 path introduces the broader choices. The current provider reference also documents certificate support missing from that older overview. Here, start with the documented code flow: PKCE S256, an exact HTTPS callback, state and nonce checks, token validation and the registered client authentication. Then make three separate decisions: how to send the authorization request, how to bind tokens to their presenter, and how to persist replacements during renewal.

How should the request travel?

Pushed Authorization Requests (PAR) let your server send authorization parameters directly to M7 using its registered authentication. The browser carries an opaque request reference instead of the full parameter set; it cannot override the stored fields.

JWT Authorization Requests (JAR) let M7 verify your client's signature on an authorization Request Object. Choose that when signed authorization inputs address a specific requirement. M7 accepts opted-in JAR at the authorization endpoint, by value or through an exact registered public HTTPS URI. It does not accept JAR at PAR or encrypted inbound Request Objects. These are distinct available paths, not a PAR-plus-JAR recipe. The provider profile sets out their boundaries.

Request signing also does not change how your client authenticates at the token endpoint.

Who must prove possession?

A provider's token signature establishes origin and integrity. It does not prove that the caller presenting that token possesses a separate key. Signed authorization responses (JARM) and response encryption serve other purposes too.

DPoP adds proof from a key bound to the token. M7 currently uses ES256. The same bound key must accompany code pickup and refresh; your protected API must enforce the proof, token binding and replay checks, including the access-token hash. Adding a sign-in button does not add those checks to your API.

The documented Web/PHP backend-for-frontend profile uses a browser-held, non-extractable key stored in IndexedDB in a secure context. Renewal must recover that key. This is a specific browser-and-PHP arrangement; it does not establish equivalent support in every browser-only library or native SDK.

mTLS is a different deployment choice. Certificate client authentication identifies your registered confidential client. Certificate-bound tokens require an additional registration setting and the same certificate at refresh and protected resources. For our booking site, that means provisioning certificates and establishing certificate handling across TLS proxies and API calls. Client authentication alone does not create resource binding. If both certificate and DPoP bindings are present, both apply.

What happens when renewal succeeds halfway?

Ordinary M7 renewal already selects strict_rotation when you omit refresh_mode. Store the complete replacement before removing its predecessor, serialize concurrent renewals, and handle uncertain responses. Binding policy is controlled by registration and provider policy, not a browser switch.

Token activation ACK adds a separate persistence lifecycle. The old refresh token remains active while the replacement is pending; the replacement's access and refresh tokens are unusable until activation. Persist the entire envelope, send ACK, and promote it only after confirmed activation. Retrying a lost ACK response is idempotent, but losing the refresh response can still leave you waiting for expiry or resolution.

For an ordinary integration, omit refresh_mode. Choose the documented Web/BFF ACK profile when you can implement its storage, activation and recovery obligations. Its extra machinery needs an operational reason.

Finally, plan revocation and logout separately. A successful revoke response does not disclose token status, and a valid signature does not establish current authority. Use applicable online checks and clear your app's sessions explicitly.

For the booking site, write down what each component must enforce before selecting the profile. It still needs its own API permissions, scopes and audience checks. A profile neither chooses those permissions nor certifies the service.