> -----Original Message----- > From: Torsten Lodderstedt [mailto:[email protected]] > Sent: Sunday, July 10, 2011 2:17 AM
> Eran Hammer-Lahav <[email protected]> schrieb: > > >The security of the protocol relies fully (implicit grant) or partially > >(authorization code) on the validation of the redirection URI. This was > >well understood by many experts but until -17, we largely ignored by > >the specification. > > what does "security of the protocol" mean? Wrt what threats? s/security of the protocol/client identification > I personally think there are various features of the protocol contributing to > the overall security level of the protocol protocol (for different threats). > For > example: user engagement and control plays an important role. We > documented those relations in the security document. User engagement is nice in theory. In practice, it is more likely to enable attacks than prevent them (e.g. phishing). > Redirect uri validation is, in my opinion, not effective for native apps and > useless if the attacker uses a native app (no matter whether the legitimate > client is a web, user agent based or native app). Thus I consider relying on > this mean exclusively is dangerous. There are no other practical means. Also, can you describe an attack involving a native application that is more problematic than the actual installation of a malicious native application? > >Using dynamic values are still fully supported: > > > > 3.1.2.2. Registration Requirements > > > > The authorization server MUST require public clients to register > > their redirection URI, MUST require all clients to register their > > redirection URI prior to utilizing the implicit grant type, and > > SHOULD require all clients to register their redirection URI prior to > > utilizing the authorization code grant type. > > > > The authorization server SHOULD require the client to provide the > > complete redirection URI (the client MAY use the "state" request > > parameter to achieve per-request customization). The authorization > > server MAY allow the client to register multiple redirection URIs. > > If requiring the registration of the complete redirection URI is not > > possible, the authorization server SHOULD require the registration of > > the URI scheme, authority, and path. > > > > So what this text basically says is: You should enforce full uri registration > & > validation but you don't have to. Which also means my use case for XSRF > prevention using other parameters is still supported. Am I wrong? Full registration is recommended. Allowing changes should be limited to the query, and doing that comes with its own can of worms to look for. But yes, your use case is still supported. Personally, I will never deploy anything but full registration of redirection URI. EHL _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
