I like the idea of that if this goes forward. It all depends on how the method of storing client info works. If it’s associated with just the issued access tokens, then it gets collected when the tokens themselves expire and are expunged. If it’s held separately, like a lot of existing OAuth deployments do with registered clients, then it’s going to need some key to kick it out.
From a protocol perspective, it’s important that the client doesn’t need to know or store any client identifier for this to work. But you’re right that it would be helpful to give implementation guidance to the AS side as well. When I was playing around with an implementation, I effectively had a secondary client storage service for this path, and that would be purged once the token was issued. — Justin On Jun 26, 2025, at 8:13 PM, emelia <eme...@brandedcode.com> wrote: Hi Justin, This sounds reasonable, though would it be wise to introduce a new "client type" of "ephemeral", so you've like public clients, confidential clients and ephemeral clients? That way your AS can know it can garbage collect that temporary client? Perhaps adding to registration data a property like maxAge or something too? Yours Emelia On 26. Jun 2025, at 23:12, Justin Richer <jric...@mit.edu> wrote: 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
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
