From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] > Since the redirection URI is required to be explicitly included > when using the authorization code grant type, the fact whether it > was pre-registered is irrelevant at this point.
That makes sense, thanks. > The client simply has to provide the redirection URI where the code > was received which will surface anyone messing with the flow in the > middle and manipulating the code. > > I have tweaked the language around the redirection verification in a > few places in -14. Can you take a look again and see if it works better > for you? I looked a bit and didn't see the change beyond the Figure 3 step (E) revision you mention below. It might be there, I didn't look for long. I'm inclined to drop the issue at this point. I'm sure you did something reasonable. > How about: > > The authorization server validates the client credentials, the > authorization code, > and ensures the redirection URI received matches the URI used to redirect > the client > in step (C). If valid, responds back with an access token. Makes perfect sense technically, but I have minor grammar issues: the list separated by commas feels irregular. I think the English teacher would write "Parallelism" in the margin in red ink. Also, the second sentence has no subject, and "responds back" is redundant. I would write: > The authorization server validates the client credentials, validates the > authorization code, > and ensures the redirection URI received matches the URI used to redirect > the client > in step (C). If valid, the authorization server responds with an access > token. Tim Freeman Email: tim.free...@hp.com Desk in Palo Alto: (650) 857-2581 Home: (408) 774-1298 Cell: (408) 348-7536 -----Original Message----- From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Friday, March 25, 2011 12:35 PM To: Freeman, Tim; oauth@ietf.org Subject: RE: Feedback on draft-ieft-oauth-v2-13.txt > -----Original Message----- > From: Freeman, Tim [mailto:tim.free...@hp.com] > Sent: Friday, March 25, 2011 11:48 AM > Tim: > > Section 2.1.1 says "If a redirection URI was registered, the > > authorization server MUST compare any redirection URI received at the > > authorization endpoint with the registered URI." Thus I conclude that > > that phrase requires the authorization server to check the redirection > > URI at step A of figure 3, but not step D, since that communication > > comes from the client instead of the user and therefore is not going > > to the authorization endpoint. If there is no requirement to check the > redirection URI in step D, it's unclear why it's there. > > Eran: > >The client sets the redirection URI used by the resource owner to > >communicate with the authorization endpoint. > > Agreed. > > >Once complete, the client uses the same redirection URI value to obtain > >a token. > > Agreed. > > >In the second step, it is used for > >verification and protection against an attack, not to redirect anything. > > I agree with that statement. My point was that the spec should say so. Since > in Section 2.1 "Authorization Endpoint" you have the sentence > > If a redirection URI was registered, the authorization > server MUST compare any redirection URI received at the authorization > endpoint with the registered URI. > > IMO somewhere in Section 2.2 "Token Endpoint" you want to at least have a > sentence like > > If a redirection URI was registered, the authorization > server MUST compare any redirection URI received at the token > endpoint with the registered URI. > > or perhaps > > If a redirection URI was registered, the authorization > server MUST compare any redirection URI received at the token > endpoint with the redirection URI used earlier at the authorization > endpoint. > > depending on what you meant. IMO the latter is more secure. Since the redirection URI is required to be explicitly included when using the authorization code grant type, the fact whether it was pre-registered is irrelevant at this point. The client simply has to provide the redirection URI where the code was received which will surface anyone messing with the flow in the middle and manipulating the code. I have tweaked the language around the redirection verification in a few places in -14. Can you take a look again and see if it works better for you? > >Explaining the purpose of the redirection URI in step E belongs in the > >security considerations section. > > I suppose we agree that the security considerations section should say why > we're doing it, but so far we're failing to discuss whether step E should say > what we're doing. IMO step E of Figure 3 should change from: > > The authorization server validates the client credentials and > the authorization code and if valid, responds back with an > access token. > > to: > > The authorization server validates the client credentials and > the authorization code and checks that the redirect URI matches > the value used at step A. If all these checks pass, it responds > with an access token. How about: The authorization server validates the client credentials, the authorization code, and ensures the redirection URI received matches the URI used to redirect the client in step (C). If valid, responds back with an access token. EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
