I’ve been seeing a lot of recent conversations trying to work around the limitations of OAuth needing a client_id as part of the syntax of the protocol. This is especially pertinent with proxy protocols like MCP, in which the client could be very ephemeral and have no real way to establish itself with the AS ahead of time. Dynamic Client Registration does work, of course, as do public clients — but both of these have their limitations. With DynReg, you end up with a client_id that might never get used again. With public clients, you still require a pre-registration but don’t really get the security benefits of registration. And for a highly dynamic system, the pre-registration doesn’t make sense. There are other approaches like having the AS fetch the client’s info from a URL, but that assumes the client can host something accessible to the AS and the AS is protected against SSRF attacks.
After talking through some ideas with Aaron, we came up with a pattern that leverages PAR and the authz code flow to allow a client to push its registration information as part of the PAR request and continue the OAuth process using a stand-in client identifier for syntactical compatibility. https://www.ietf.org/archive/id/draft-richer-oauth-pushed-client-registration-00.html The short version of the process goes like this: 1. Client makes a PAR request with a special client_id value to trigger this (we’ll use “dynamic” in the example but it’s a fixed string that’s always the same for all clients). The request includes its redirect URI and optionally any other DynReg client metadata, and can also include any keys and challenges for PKCE and client auth 2. AS returns a request_uri like normal PAR, but this creates an internal transaction that is bound to the parameters sent in (1) 3. Client calls the authz endpoint with the request_uri and the special client_id value, “dynamic” 4. AS loads the configuration based on the request_uri and processes the request as usual 5. AS returns the “code” and anything else relevant, as usual 6. Client calls the token endpoint with the code, PKCE verifier, proof of its keys from (1), and the client_id value of “dynamic”; could include a DPoP/MTLS proof too 7. AS loads the approved request from the “code” value and processes it as usual 8. AS returns a token as usual 9. Client uses the token as usual While it was MCP that brought this up, the pattern also shows up in other places like connecting instances of an email client to instances of an email server. I’d like to get some time on the agenda for Madrid to discuss this draft in greater detail. — Justin
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
