Let apps work together, with your permission

Useful apps often need a little help from another service. You might be writing a post and want to bring in a file you already keep elsewhere. A good connection should make that easy while keeping clear who is asking, what they may do and where that permission ends.

M7 Identity supports delegated app access through approved application connections and OAuth token exchange. One app can call a connected service on your behalf, within the permissions you and the applications already have.

One person, two apps, a clear purpose

Imagine Bob uses an app called Blog to prepare a post, and keeps a document in an app called Files. This is an illustrative example: Bob wants Blog to read that document so he can use it in his post.

Bob's authorization matters, but so does the relationship between the apps. Blog must be allowed to request delegated access, Files must accept it, and their connection must be active and approved. An app connection cannot create permission Bob never granted.

Approval does not necessarily mean another consent screen every time Blog needs a file. The exchange uses Bob's existing authorization and the approved connection, with the receiving app's policy setting the limits.

The result is a focused request: Blog acts for Bob, asking Files for permitted access. It does not need to pass Bob's original login token to Files for that purpose.

A token for the receiving service

RFC 8693 defines OAuth token exchange. In M7's supported flow, the caller must be an authenticated app able to keep its client credentials private on a server. It exchanges an active M7 user access token issued to it for a token intended for one approved receiving service.

That token still represents Bob and identifies Blog as the app doing the work. Its permissions must fit the original token, the calling app, the connection and the receiving service's exchange policy. Asking for more does not expand those limits.

This is user delegation. A background service using its own machine credentials acts as itself; Blog here is acting on Bob's behalf.

Files still makes the decision about the document. It checks the token and its intended recipient, the permitted operation and its own resource access rules. A token addressed correctly to Files is not permission to read every file there.

M7's current consumer flow supports one target and one delegation hop. Blog can call Files through that approved connection; the resulting token cannot be exchanged onward into a chain of other services.

Permission has an end

Continuing access is a deliberate choice. An access-only exchange does not include a refresh credential. Where offline access is explicitly authorized, renewal rechecks the current app, connection and permission policies and cannot extend the delegation's absolute expiry.

Withdrawing connection approval or permission for exchange blocks new exchanges and delegated renewals. It does not automatically end Bob's original login. An already issued token may remain usable until expiry if the receiving service checks only its signature; immediate enforcement needs applicable live token or connection checks.

For builders, that gives the connection a useful shape: a named app doing a limited job for a person, a known receiving service, and a clear boundary when permission changes. For Bob, it means his apps can work together while each service remains responsible for the access it allows.

To set up a connection, start with the application connections guide, then use the Token Exchange contract for the request and policy details.