Am 01.06.2011 08:56, schrieb Brian Eaton:
On Tue, May 31, 2011 at 11:41 PM, Chuck Mortimore
<[email protected]> wrote:
It’s not entirely necessary; I’m just having a tough time figuring out any
practical difference between the implicit grant flow, and the webserver flow
with no credentials. In general I agree with your points, but I think we
have a similar, perhaps worse, scenario with relaxing the need for
credentials on the web server flow.
No doubt. =) I think it's unfortunate that the spec was changed to
make the client credentials optional for the web server flow. As you
say, it's a security problem for web apps. We are treating the client
secret as mandatory in our deployments, and basically everyone who
deploys the web server flow should do the same. It's a shame the spec
is so vague on this point.
The root cause of the spec ambiguity was disagreement over how to
handle secrets for installed applications. I can think of three paths
forward.
- split out "installed app flow" from "web server flow". Use a new
grant type. (DON'T switch installed apps to use the "implicit" grant
type. That doesn't work either, because it doesn't return a
long-lived credential. DON'T have the implicit grant type return a
refresh token directly, either, since that causes serious security
problems for real web apps that can keep client secrets.)
So far every grant type represented a different protocol flow (not
client type). Why do you want to define different grant types for
basically the same flow but different client
identification/authentication policies? What if a service provider is
able to securely deploy instance-specific secrets to its native apps
(e.g. in intranet scenarios - see Chuck's posting). Shall it use the
"web server flow" then? The current text keeps client authentication and
the grant type orthogonal. I would suggest to stick to this approach.
- make the client secret mandatory, but tell people who are offended
by client secrets in installed apps to use the string "notasecret" for
all installed apps.
How is that any different from just not using a secret from a security
perspective?
- ignore the problem and leave the spec vague and insecure.
Could you please describe what you consider "insecure"? I think we have
the challenge to defining a secure protocol while supporting the needs
of different client types.
Past versions of the spec entirely focused on client secrets as
mechanism to validate a client's identity. This created the false
impression that native apps either
1) must use the implicit grant type (which does not support refresh
tokens), or
2) use the authz code grant type in conjunction with a (weakly/none
protected) secret in order to comply with the text of the specification.
3) It is also interesting to note that people have started to think
OAuth does not support native apps!
(1) results in a sub-optimal user experience since the app has to go
through the (interactive) authz cycle with every startup or
the authz server issues long-living a access tokens (?) or
(even worse) the authz server automatically issue access tokens
for sub-sequent requests by the same client (how to determine "same"?).
(2) creates a _false_ impression of security because the authz server
authenticated the clients. But the authorization server _must not_ rely
on such a secret for validating the client's identity.
The security consideration section clearly states this now.
regards,
Torsten.
In terms of your example, wouldn’t basic XSRF protection in the state param
protect?
Nope. Assume the following scenario:
- bad guy has stolen refresh token
- client web server has detected attack and changed their client secret
- bad guy wants to find a way to keep using the refresh token
If refresh tokens are returned without client authentication, the bad
guy can do it as follows:
- visit client. log in as account badguy1234.
- client redirects to authorization server, including state=1234
- bad guy ignores redirect to authorization server, visits client
callback server with refresh_token=stolen&state=1234
- client picks up stolen refresh token and associates it with badguy1234.
- whenever badguy1234 visits the client web site, he can see data from
the stolen refresh token.
Cheers,
Brian
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
