Am 16.06.2011 22:30, schrieb Brian Eaton:
On Thu, Jun 16, 2011 at 1:25 PM, Torsten Lodderstedt
<tors...@lodderstedt.net <mailto:tors...@lodderstedt.net>> wrote:
no I'm saying people will use real secrets and rely on them - just
as with OAuth 1.0
=)
People are going to ignore what the spec says on this. If you read
through the mailing list threads on this topic, you'll notice several
people have stated quite clearly that they are going to be baking
secrets into installed applications, and that they think they have
reasonable mitigations in place for the security risk.
It's not that those people are dumb, either. They understand exactly
what they are doing. And their native applications are not going to
be any less secure because of the choices they are making.
If those people have reasonable means in place to protect secrets on
deployment channels and in the local installation - fine. I would be
eager to learn more about those means because I would be willed to
utilize them as well.
My current assumption is that in a open market scenario secrets can be
reverse engineered from binary or source code. Since the same secret is
used for all installations of the same software, an attacker can utilize
it to built a counterfeit app. Because of this risk, I would not
recommend to rely on the secret for authenticating such an app.
The situation may vary for corporate/enterprise scenarios, where an
application can be installed by an administrator and equiped with an
installation specific id/secret during this process. In that case, the
authz server can rely on the secret for authenticating and authorizing
the client.
That's why the security considerations section states:
... The authorization server MAY issue
a client password or other credentials for a specific installation of
a native application on a specific device.
regards,
Torsten.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
