Snipping out everything I agree with, there's only this remaining, including
some context so this email might make sense in isolation:
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.
>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.
Actually, I'm a little confused here. The spec seems to allow registering some
but not all components of the redirect URI. In that case, should step E be
checking that all of the redirect URI is equal to the value used in step A, or
checking that it's consistent with those components that were registered? The
security works better if you do the former, but I'm not aware that the spec
says that anywhere.
Tim Freeman
Email: [email protected]
Desk in Palo Alto: (650) 857-2581
Home: (408) 774-1298
Cell: (408) 348-7536
-----Original Message-----
From: Eran Hammer-Lahav [mailto:[email protected]]
Sent: Thursday, March 24, 2011 11:41 PM
To: Freeman, Tim; [email protected]
Subject: RE: Feedback on draft-ieft-oauth-v2-13.txt
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf
> Of Freeman, Tim
> Sent: Tuesday, March 15, 2011 2:56 PM
<snip>
I think authorization, user-agent, endpoint are well understood terms among
those working with HTTP which OAuth clearly requires a certain level of
familiarity, but I'll sprinkle some references to make it clearer.
> Section 2.1.1, "Redirection URI". "If a redirection URI was registered, the
> authorization server MUST compare any redirection URI received at the
> authorization endpoint with the registered URI." Section 2.1 says the
> authorization endpoint is where the user (presumably also the resource
> owner, using the user-agent) interacts with the authorization server.
> Therefore, I conclude that the communication path between the client and
> the authorization server in figure 3 does not happen by the authorization
> endpoint, since the client is not the user.
The authorization endpoint response to the user-agent, redirects it back to the
client's callback URI.
> I suspect it's the token endpoint,
> since there's a token in Figure 3 step E. (If that's wrong, section 2.1
> needs to
> be changed to say that the client uses the authorization endpoint too.)
Yes.
> 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.
The client sets the redirection URI used by the resource owner to communicate
with the authorization endpoint. Once complete, the client uses the same
redirection URI value to obtain a token. In the second step, it is used for
verification and protection against an attack, not to redirect anything.
Explaining the purpose of the redirection URI in step E belongs in the security
considerations section.
> Section 3 "Client Authentication". I think the intent is that client
> identifiers
> are public, since they are disclosed to the user-agent in section 4.1,
> "Authorization Code". You might want to say so, otherwise one might reason
> that clients are required to publish their client identifiers (in section
> 4.1), and
> client identifiers are part of the client credentials (section 3), no clients
> can
> keep their credentials confidential, so no authorization servers should issue
> client credentials to any clients.
> Perhaps client identifiers are not part of the client credentials?
New text:
Client credentials are used to identify and authenticate the client.
The client
credentials include a client identifier - a unique string issued to the
client to
identify itself to the authorization server. The client identifier is
not a secret, it is
exposed to the resource owner, and MUST NOT be used alone for client
authentication. Client
authentication is accomplished via additional means such as a matching
client password.
> Figure 3 in section 4.1. "User authenticates" is a two-way communication
> because the authorization server will typically prompt the user to
> authenticate, but the arrow only points from user-agent to authorization
> server, so there is no opportunity to prompt. I think you want arrows
> pointing in both directions on the "User authenticates" path.
The arrow passes through the user-agent to the resource-owner... the
limitations of ascii art.
> We should get clear on whether the redirect URI is public or not. If it's
> public,
> and the client, all possible entities wishing to impersonate the client, and
> the
> authorization server all know it, then there's no value in communicating it
> from the client to the authorization server. If it's private, that should be
> specified when the redirection URI is introduced at step A, and the
> alternative of omitting it because it's common knowledge to the client and
> the authentication server (in section 2.1.1, first paragraph) goes away since
> it's disclosed to (possibly adversarial) user agents in Figure 3, step A.
It's a session fixation attack protection which I can't recall anymore. It's
explained somewhere in the list archives.
> Figure 3 step B: You'll need to make clear that if the resource owner is a
> human, there will be a need to uniquely identify the client and the requested
> resource in a human-readable way. For example, if the actual client is
> "Microsoft, Inc.", and I am able to register a client "M1crosoft, Inc.", and
> humans in practice cannot distinguish "Microsoft" from "M1crosoft", people
> might give my client authorizations that they intended to give to Microsoft.
>
> I can imagine using social engineering to leave the user in the middle of one
> OAuth exchange while they start another in another window, and if popup
> windows are used for interacting with the user while authenticating, they
> might authenticate the wrong client. In other words, the rhythm of the
> interaction is not a reliable cue to tell a human which client he's
> authenticating to, so the human-readable name of the client must be
> unambiguously stated on the screen when the user is accepting or denying
> the authorization.
>
> The human-readable name corresponding to a client id has to come from a
> database on the authorization server, since the client cannot be trusted to
> provide it.
>
> A similar scenario can be created where imperfect human reading
> comprehension can cause authentication to the wrong resource, if the
> operators of the authorization server allow arbitrary names for resources.
All good feedback for the security considerations section.
> Section 10.2.2: It says the "state" parameter can be present in the
> authorization request and authorization response. I suppose the
> authorization response is the response to the authorization request, but in
> the figures up to this point the phrases "authorization grant" (Figure 1) or
> "authorization code"
> (Figure 3) are used, not authorization response. I see that there is a
> section
> 4.1.2 "Authorization Response". It would be good to identify which arrows in
> Figures 1 and 3 are Authorization Responses (I suspect B and C, respectively).
> It looks like that text would not fit into the space available in the figure,
> but it
> would fit well in the steps listed below each of the figures.
Just (C).
EHL
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
