Signed, checked, ready: JAR comes to M7 Identity
Your app knows what it is asking for. Now it can sign those details so M7 can verify them.
M7 Identity now supports JWT Secured Authorization Requests (JAR): an opt-in, per-client way to attach a verifiable signature to an authorization request before a person is asked to continue.
A clearer handoff at the moment it matters
Authorization requests already make a useful handoff: an app sends the details of what it needs, and M7 presents the right next step to the person. JAR adds a firm check to that handoff. The app packages the request into a signed JWT Request Object; M7 verifies it and uses the signed values for the transaction.
That means the application can make its intended client identity, return URL, and requested permissions part of one signed statement. If an outer query value conflicts with a value in that statement, the signed value controls. M7 rejects tampered, replayed, or invalid JAR Request Objects.
One practical flow
Imagine a web app that is about to ask for access on a person’s behalf. It knows its client ID, its registered callback URL, and the permissions it needs. With JAR enabled, the app signs those details and sends the Request Object to /authorize. M7 checks the signature before continuing, so the request being acted on is the request the app signed.
An app can send that object directly in request. It can also provide a request_uri that points to it. In that second case, the URI must be an exact HTTPS URL registered for that client. M7 retrieves it once for the transaction and works from that verified snapshot, so a later edit at the URL cannot change an in-progress request.
An opt-in tool for teams that need it
JAR is available through a client’s Request Policy, using either an inline public JWKS or a remote JWKS. It is a per-client choice: enable it where signed authorization details add value to your flow, without changing how every application uses M7 Identity.
Signing is not encryption. A JAR signature lets M7 check that the request came from the expected client and has not changed; it does not hide the request parameters. Encrypted Request Objects are a separate capability.
For builders who want a more explicit, checkable authorization handoff, JAR brings the useful part into focus: sign the details you mean to send, and M7 can check them before the person approves.