From 4.2.1 below:
The authorization server validates the request to ensure all
required parameters are
present and valid. The authorization server MUST verify that
the redirect URI to which
it will redirect the access token matches a redirect URI
pre-registered by the client.
The authorization server MUST verify the scheme, authority, and
path components of the
redirection URI and SHOULD verify the query and fragment
components.
What does it mean for the authorization server to "verify the fragment
component"?
From: Eran Hammer-Lahav <e...@hueniverse.com>
To: Brian Eaton <bea...@google.com>, "oauth@ietf.org"
<oauth@ietf.org>
Date: 04-07-11 01:25 PM
Subject: Re: [OAUTH-WG] draft 16 review notes
Sent by: oauth-boun...@ietf.org
From: Brian Eaton <bea...@google.com>
Date: Sun, 22 May 2011 20:38:53 –0700
1.4.1 Authorization Code
maybe expand the section on important security benefits. “The use of
authorization codes also improves the ability to recover in the event
of compromise of an application server or authorization server.”
Can you explain?
4.2.1 Authorization Request
Validation of the redirect_uri parameter is more important for the
implicit grant type. Section 2.1.1 leaves registration of the
redirect URI as “SHOULD”. It’s a “MUST” for the implicit flow.
Suggested language:
The authorization server validates the request to ensure all required
parameters are present and valid. The authorization server MUST
verify that the redirect URI to which it will redirect the
authorization code matches a redirect URI pre-registered by the
client. The authorization server SHOULD verify the scheme,
authority,
and path of the redirect URI. The authorization server MAY verify
the
query parameters as well.
Changed it for now to:
The authorization server validates the request to ensure all required
parameters are
present and valid. The authorization server MUST verify that
the redirect URI to which
it will redirect the access token matches a redirect URI
pre-registered by the client.
The authorization server MUST verify the scheme, authority, and
path components of the
redirection URI and SHOULD verify the query and fragment
components.
I'm still not happy with this and want something stronger.
4.3.2 Access Token Request
Really need language in here about the risk of brute force attacks on
passwords.
How about:
Since this access token request utilizes the resource owner's
password, the
authorization server MUST protect the endpoint against brute
force attacks.
Section 10. Security Considerations
There are various security risks mentioned in the OAuth WRAP security
considerations that seem worth mentioning here:
http://trac.tools.ietf.org/wg/oauth/trac/raw-attachment/wiki/SecurityConsiderations/OAuthWRAP2.0SecurityConsiderations.pdf
Care to extract and edit for inclusion?
Section 10.1 Client Authentication
nit: “MUST NOT issue client passwords to installed apps” is a dead
letter, it is not going to change standard industry practice in the
slightest. The language from section 3 is more constructive. I’d
suggest the following language for section 10.1 instead
“The authorization server MUST NOT assume that native or user-agent
based applications can maintain the confidentiality of client
secrets.”
That does conform with industry practice, so it’s more likely to be
implemented.
Do we have consensus for this change?
Section 10.2 Client Impersonation
I like the content of this section, but it seems to mix several
different topics.
- general risks of native applications
- security considerations for “immediate mode”, where authorization
requests are processed without end-user interaction.
- validation rules for redirect URIs
- open redirectors
- access token design
Most of those merit separate discussion.
Need proposed text.
10.3 Access Token Credentials
“When using the implicit grant type, the access token credentials are
transmitted in the URI fragment, which can expose the credentials to
unauthorized parties.”
That’s basically FUD. This should be made much more specific. It
falls into the general category of security considerations for
redirectors and clients...
Need proposed text.
10.9 Authorization Codes
MUST be single use is a dead letter, because it requires atomic
operations at scale. Even things like password changes are not
atomic
in user databases of moderate size. Authorization codes might be
generated quite frequently (e.g. when “immediate mode” flows are
used), so a MUST for an atomic operation is unrealistic.
Need proposed text.
EHL
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
