> -----Original Message-----
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] 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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
