Inline. On 2013-06-06, at 5:54 PM, Sergey Beryozkin <sberyoz...@gmail.com> wrote:
> Hi > On 06/06/13 14:38, John Bradley wrote: >> Perhaps it is better to say that from a security point of view a client must >> only be redirected back to a URI that exactly matches a pre registered >> redirect URI. >> >> The reasons for that should be clear from Facebooks recent issues with >> trying to pattern match. >> >> In the instance where there is exactly one registered redirect_uri and no >> redirect_uri is sent in the request redirecting to the registered URI is >> fine. > > OK, I think I understand, eventually, even if a redirect_uri is not available > as a parameter then the single (and it has to be a single only) > pre-registered redirect_uri is used, so the requirement expressed in your > first sentence above is met. > >> >> In code flow with a confidential client sending the redirect_uri with the >> code to the token endpoint helps mitigate the problem of unregistered >> redirect_uri, however it leaves open possibilities for the code to be >> stolen. It can't be used by an attacker to get the token, but it can be >> replayed at the legitimate client and relies on the AS correctly comparing >> the redirect_uri sent ing the authorization request to the redirect_uri sent >> to the token endpoint. >> >> That is theoretically secure but is not something a client can verify, it >> also places additional state requirements on the AS. > > I'm a bit lost here, sorry. Are you talking here about might happen if a > client has not pre-registered redirect_uri ? If yes then the above is clear > (I think) Yes. A client that is not confidential must always register redirect_uri even if it is using code flow. Otherwise anyone can use the client_id with any redirect_uri. A confidential client using code flow is allowed not to have a registered redirect_uri as there is a check by sending the redirect_uri to the token endpoint. However I personally think that is risky as that is not as likely to be well tested. So you can if both sides know what they are doing, but I wouldn't recommend it. > >> >> Note Connect always requires the rediret_uri to be sent even if there is >> only one redirect_uri registered. That is for interoperability reasons. >> If some AS always required it as they are allowed to by the spec and some >> didn't require it, the client always needs to send it to work with any AS. >> > Sure, that makes sense; I'm actually thinking of making it configurable for > us may be, > > Many thanks > > Sergey >> John B. >> >> On 2013-06-06, at 3:17 PM, Sergey Beryozkin <sberyoz...@gmail.com> wrote: >> >>> Hi, >>> >>> I'd like to clarify one thing with respect to the treatment of redirect_uri. >>> >>> My understanding it is possible for a client application to pre-register a >>> redirect_uri but not actually specify it as a query parameter when >>> redirecting a user back to the Authorization service - in which case it is >>> that pre-registered redirect URI which AS will eventually use to redirect >>> the user back to. >>> >>> Is it still considered to be a safe-enough approach ? If yes - then both >>> confidential and public(implicit) clients are OK to use it this approach of >>> dropping a redirect_uri during the initial user redirects ? >>> >>> I'm just asking given that I recall the experts recommending that a current >>> redirect_uri parameter must be exactly equal to the pre-registered one. >>> >>> Thanks, Sergey >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
