What issue of redirect_uri fragments? For implicit and the hybrid flows the fragment is used to pass back the parameters.
In Connect we were explicit on what parts of the URI are compared: One of these registered Redirection URI values MUST exactly match the redirect_uri parameter value used in each Authorization Request, with the matching performed as described in Section 6.2.1 of [RFC3986] (Simple String Comparison). In the IETF version we point back to Section 2 of RFC6749 The redirection endpoint URI MUST be an absolute URI as defined by [RFC3986] Section 4.3. The endpoint URI MAY include an "application/x-www-form-urlencoded" formatted (per Appendix B) query component ([RFC3986] Section 3.4), which MUST be retained when adding additional query parameters. The endpoint URI MUST NOT include a fragment component. So the redirect_uri can't contain a fragment. In RFC6749 there is some wiggle room for comparing URI components. When a redirection URI is included in an authorization request, the authorization server MUST compare and match the value received against at least one of the registered redirection URIs (or URI components) as defined in [RFC3986] Section 6, if any redirection URIs were registered. If the client registration included the full redirection URI, the authorization server MUST compare the two URIs using simple string comparison as defined in [RFC3986] Section 6.2.1. So we are not adding any additional constraints beyond RFC6749. The redirect_uris meta-data is optional. A client using the client credentials or resource owner flow wouldn't have a redirect uri to register. John B. On Jul 8, 2014, at 11:45 PM, Phil Hunt <phil.h...@oracle.com> wrote: > What about the whole issue of redirect_uri fragments? > > Are there any issues where a client for some reason can’t register a perm URI > at registration time? > > Phil > > @independentid > www.independentid.com > phil.h...@oracle.com > > > > On Jul 8, 2014, at 8:39 PM, Richer, Justin P. <jric...@mitre.org> wrote: > >> I can see where you're going with it. Requiring clients to use it implies >> that servers need to enforce it. In the security considerations we currently >> have: >> >> For clients that use redirect-based grant types such as >> "authorization_code" and "implicit", authorization servers MUST >> require clients to register their "redirect_uri" values. This can >> help mitigate attacks where rogue actors inject and impersonate a >> validly registered client and intercept its authorization code or >> tokens through an invalid redirection URI or open redirector. >> >> However, in previous versions up to -17, this was a SHOULD, not a MUST. This >> is a normative requirement change for server implementors and I want to make >> sure everyone realizes was made. As of a handful of versions ago, our server >> started to enforce this anyway. What have other developers done with this, >> and would it be difficult to comply with the new requirement? >> >> -- Justin >> >> On Jul 8, 2014, at 10:22 PM, Mike Jones <michael.jo...@microsoft.com> wrote: >> >>> That’s close but not quite right, since use is required by clients when >>> using redirect-based grant types. We could however, use this language: >>> >>> The implementation and use of all client metadata fields is OPTIONAL, other >>> than "redirect_uris" >>> which is REQUIRED for authorization servers that support and clients that >>> use redirect-based grant types. >>> >>> redirect_uris (...) Authorization servers that support dynamic registration >>> of clients using redirect-based >>> grant types MUST implement support for this metadata value and clients that >>> use redirect-based grant types MUST use this parameter. >>> >>> -- Mike >>> >>> >>> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Richer, Justin P. >>> Sent: Tuesday, July 08, 2014 6:44 PM >>> To: oauth@ietf.org list >>> Subject: [OAUTH-WG] Dynamic Client Registration: comment on metadata >>> requirements >>> >>> In draft -18, we clarified the optionality of the client metadata >>> parameters in § 2 with new text, including the sentences: >>> >>> The implementation and use of all client metadata fields is OPTIONAL, other >>> than "redirect_uris". >>> >>> redirect_uris (...) Authorization servers MUST implement support for this >>> metadata value. >>> >>> >>> However, since OAuth core defines two non-redirect flows (client >>> credentials and password) and we're about to publish another one >>> (assertions), I suggest that we adopt the following clarification: >>> >>> The implementation and use of all client metadata fields is OPTIONAL, other >>> than "redirect_uris" >>> which is REQUIRED for authorization servers that support redirect-based >>> grant types. >>> >>> Authorization servers that support dynamic registration of clients using >>> redirect-based >>> grant types MUST implement support for this metadata value. >>> >>> I think this language brings the requirement more in line with the intent >>> and would like comment from the WG. >>> >>> -- Justin >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
