Here is my proposal for the new section: 2.4. redirect_uri Management
The OAuth Security BCP [I-D.ietf-oauth-security-topics] as well as OAuth 2.1 [I-D.ietf-oauth-v2-1] require an AS to excactly match the redirect_uri parameter against the set of redirect URIs previously established for a particular client. This is a means to early detect attempts to impersonate a client and prevent token leakage and open redirection. As a downside, it makes client management more complex since the redirect URI is typically the most volatile part of a client policy. This requirement MAY be relaxed by the AS, if a confidential client uses pushed authorization requests since the AS authenticates the client before the authorization process starts and that way ensures it interacts with the legit client. The AS MAY allow such clients to specify redirect_uri values not previously registered with the AS. This will give the client more flexibility (e.g. to mint AS-specific redirect URIs on the fly) and makes client management much easier. It is at the discretion of the AS to apply restriction on redirect_uri values, e.g. the AS MAY require a certain URI prefix or allow only a query parameter to vary at runtime. Note: The aibility to set up transaction specific redirect URIs is also useful in situations where client ids and correspoding credentials and policies are managed by a trusted 3rd party, e.g. via client certifiates containing client permissions. Such an externally managed client could interact with an AS trusting the respective 3rd party without the need for an additional registration step. > On 29. Aug 2020, at 17:22, Justin Richer <jric...@mit.edu> wrote: > > I completely agree with the utility of the function in question here and it > needs to be included. I’m in favor of creating a dedicated section for > redirect_uri management, so that we can explain exactly how and why to relax > the requirement from core OAuth. In addition, I think we want to discuss that > the AS might have its own restrictions on which redirect URIs an > authenticated client might be able to use. For example, registering a client > with a Redirect URI prefix, or allowing only a query parameter to vary at > runtime. All of these can be enforced in PAR because the client is presenting > its authentication, as you point out, so the AS can determine which policies > should apply. > > — Justin > >> On Aug 29, 2020, at 7:52 AM, Torsten Lodderstedt <tors...@lodderstedt.net> >> wrote: >> >> >>> >>> >>> ¶6: Does the AS really have "the ability to authenticate and authorize >>> clients”? I think what we mean here is "the ability to authenticate clients >>> and validate client requests”, but I’m not positive of the intent. >>> >>> I think the intent is that the AS can check whether a client is authorized >>> to make a particular authorization request (specific scopes, response type, >>> etc.). But checking authorization to request authorization is confusing >>> wording. I think your working is less confusing and still allows for the >>> intent. >>> >>> I'll let Torsten interject if he feels differently as I think he originally >>> wrote the text in question. >> >> that was the original intent. I think “validate" is fine. >> >>> >>> >>> >>> ¶7: I’m not sure I buy this example. Even if the clientID is managed >>> externally, the association with a set or pattern of allowed redirect URIs >>> is still important, and the AS will need to know what that is. I think this >>> example could lead an AS developer to (erroneously and dangerously) >>> conclude that they don’t have to check any other values in a request, >>> including scope and redirect URI. It’s important that DynReg doesn’t >>> alleviate that issue, but removal of DynReg doesn’t really change things in >>> that regard. Suggest removing example or reworking paragraph. >>> >>> I'm going to have to defer to Torsten on this because, to be honest, I'm >>> not too sure about it myself. I tend to lean towards thinking the draft >>> would be better off without it. >>> >> >> In the traditional authorization flow, the redirect_uri serves as way to >> make sure the AS is really talking to the legit client and the allowed >> redirect_uri values are determined by the legit client at registration time >> (might be manually). >> >> With PAR, we have a much stronger means to ensure the AS is talking to the >> legit client. That’s why I don’t see an issue with letting the client set a >> per transaction redirect_uri. This will give the client more flexibility >> (mint AS-specific redirect URIs on the fly) and makes client management much >> easier since redirect URIs are the most volatile part of a client policy. >> >> It also makes use of OAuth much easier in deployments where client >> identities are managed by external entities (even without any idea of >> OAuth). A prominent example is open banking in the EU (aka PSD2). The >> (technical) identity of any PSD2-licensed client is asserted by an eIDAS >> compliant CA in a special X.509 certificate. Those certificates contain the >> permissions (access to account information and/or payment initiation >> allowed) and the identity (member state specific). But they don’t contain >> OAuth policy values. Nevertheless, the regulation requires any financial >> institution in the EU to at runtime, without any registration, to accept and >> process calls from any licensed PSD2 clients. >> >> There are two ways to cope with it in OAuth context: >> a) use dynamic client registration with the X.509 cert as credential. >> Unfortunately, RFC 7591 does not support other client authentication means >> then an initial access token. Beside that, it would violate the text of the >> regulation. >> b) establish a redirect URL with every transaction. This is the recommended >> approach in at least one of the PSD2 specs. >> >> PAR is a clean way to solve that problem. >> >> I don’t want this text to cause confusing. On the other hand this potential >> of PAR is way too important to not mention it at all. What about moving it >> into a special section "redirect_uri management”? >> >>> >> > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
