Hi Dave,
there has been a long debate about native client security and you can
also find a comprehensive analysis in the security document.
It's just a fact that such clients cannot reliably be authenticated in a
public environment (even if malicious clients can be detected in some
cases). So it is the responsibility of the resource owner to validate
the authenticity/trustworthiness of an app before using it. The authz
server's task is to authz access to cloud resources, so it asks the
resource owner for consent. Once the consent is given, the refresh token
itself represents the fact that the holder should be a legitimate client.
regards,
Torsten.
------------------------------------------------------------------------
*From: * Dave Rochwerger <da...@quizlet.com>
*Date: *Wed, 14 Sep 2011 13:45:42 -0700
*To: *Torsten Lodderstedt<tors...@lodderstedt.net>
*Cc: *<oauth@ietf.org>
*Subject: *Re: [OAUTH-WG] OAuth2 Implementation questions (client secret
and refresh tokens)
Is this a security issue in the OAuth2 process then (for mobile apps
using the authorization code flow)?
1. The draft says that mobile apps should be considered public clients
because mobile apps can be decompiled and can not keep their credentials
private.
2. In this case then, the draft says for these mobile apps to not
authenticate with the secret and instead for the server to verify the
redirect URI (and make it mandatory).
3. You said that verifying the redirect URI is not good enough to verify
the client's identity.
What am I missing?
Thanks,
Dave
On Wed, Sep 14, 2011 at 12:51 PM, Torsten Lodderstedt
<tors...@lodderstedt.net <mailto:tors...@lodderstedt.net>> wrote:
Hi Dave,
redirect URI validation does not authenticate a client. For example,
a URI registered for a private web client could be used by a
(malicious) native app to assume the web app's identity. The client
secret, in contrast, can be used to authenticate it.
regards,
Torsten.
Am 14.09.2011 19:12, schrieb Dave Rochwerger:
Thanks for the follow up, Torsten.
Whilst I have your attention - any thoughts on my second question,
about the use of a client secret?
If for all clients we mandated registered URIs and verified them
(whether they are private and public), what additional security does
the client secret actually provide for private clients in the
authorization code flow?
Thanks,
Dave
On Wed, Sep 14, 2011 at 7:20 AM, Torsten Lodderstedt
<tors...@lodderstedt.net <mailto:tors...@lodderstedt.net>> wrote:
Hi Dave,
On Wed, 7 Sep 2011 17:22:14 -0700, Dave Rochwerger wrote:
1. "The user does not have to be present."
Maybe I should be more clear. What benefit does that
have over just a
long-lived (forever) access token? The cost is the extra
complication for
3rd party developers to have to worry about refresh
tokens. I can not see
a benefit in our model (everything over SSL, etc) to use
refresh tokens.
I want to use refresh tokens - but only if there is a
reason for them,
which I can not see at the moment.
The benefit of refresh tokens significantly depends on your
access token design. If your access tokens are just a
pointer to a database you lookup on any API call, the only
benefit if token rotation (coming back to this topic below).
But your access tokens could also directly contain all user
data you need to actually authorize API access. That way you
could save DB lookups, which scales much better. In this
model, revocation is much can be easier implement using
refresh tokens. I think this is what Eran refered to.
2. "As Eran points out, you'd have to have do a DB
lookup to have true
revocation."
The act of revoking tokens is not a common occurrence,
DB lookups to
revoke tokens is not a concern as there is more time
spent by the user
navigating the UI (or network latency, etc) than the
cost of the DB call.
3. "In this sense you get the best of a long-lived
credential, combined
with good key rotation and authorization re-verification
without having
to re-involve the end-user."
That all sounds good, but in our situation (all SSL,
etc) - what do we
want key rotation and re-verification for? I fail to see
a reasonable
vector for access token leakage to warrant any of this
in our case.
rotation is a mean to detect tokem theft from the device
(see also
http://tools.ietf.org/html/draft-lodderstedt-oauth-security-01#section-4.1.2).
regards,
Torsten.
On Wed, Sep 7, 2011 at 5:08 PM, Phil Hunt wrote:
See below...
Phil
@independentid
www.independentid.com <http://www.independentid.com>
[11] phil.h...@oracle.com
<mailto:phil.h...@oracle.com> [12]
On 2011-09-07, at 4:57 PM, Dave Rochwerger wrote:
Hi Phil,>> The client is then forced to
periodically reauthenticate
(without the user) before getting a new access
token.
What benefit does that have?
The user does not have to be present.
Refresh also gives the authzn server a
chance to revoke access.
Hence it is better to use shorter lived access
tokens with long lived
refresh tokens.
That doesn't follow - we can just as easily
revoke the single
long-lived access token.
As Eran points out, you'd have to have do a DB
lookup to have true
revocation. But, by having a short expiration time
on the access token
(say 1 hour or less), you get quasi-revocation which
has to be
re-validated after the access token expires and the
client has to
re-authenticate and provide a valid refresh token.
In this sense you
get the best of a long-lived credential, combined
with good key
rotation and authorization re-verification without
having to re-involve
the end-user.
Dave.>
On Wed, Sep 7, 2011 at 4:24 PM, Phillip Hunt wrote:
You can also use a long lived refresh token
in combination with a
short access token. The client is then
forced to periodically
reauthenticate (without the user) before
getting a new access
token.
Refresh also gives the authzn server a
chance to revoke access.
Hence it is better to use shorter lived
access tokens with long
lived refresh tokens.
Phil
On 2011-09-07, at 15:27, William Mills wrote:
I'll talk to the refresh token question:
they give you a hook for
extensibility and key rotation. If you
want to rotate your
encryption keys or extend the data
carried in the token in any
way then you want to be able to cleanly
refresh your tokens. Note
that the refresh flow allows you to
issue a new refresh token at
the same time. It also allows a clean
path to convert tokens in a
new client if you decide you want SAML
tokens instead of MAC for
example.
If you want those things you want to use
refresh tokens. You can
have long lived access tokens too, and
just use the refresh
tokens when you want to do something new
with the access tokens.
-bill
-------------------------
FROM: Dave Rochwerger
TO: oauth@ietf.org
<mailto:oauth@ietf.org> [2]
CC: Quizlet Dev Team
SENT: Wednesday, September 7, 2011 2:15 PM
SUBJECT: [OAUTH-WG] OAuth2
Implementation questions (client
secret and refresh tokens)
Hi all,
I have been implementing OAuth2 based on
the various drafts for
our new API. Initially, I implemented
everything as per the spec,
but due to our particular scenario and
restrictions we have in
place, there are some fundamental
questions that I am unable to
defend.
I am hoping this group could help answer
them for me.
Our scenario:
==========
* We are implementing an API to allow
3rd party developers to
access users' protected resources via
their applications. The
applications will mostly be native phone
apps, but some will have
web server backends (javascript-only
applications are not a
concern at the moment).
* We want to provide very long-lived
(forever) tokens.
* We are implementing the "authorization
code" flow as that seems
best suited to us (we don't want the
implicit flow because
end-users would have to re-authorize
every hour).
Our architecture:
============
* We control both the API server and the
authorization server.
* All requests to protected resources
(ie: to the API server) are
always done over SSL.
* All requests to the authz server
(token and authorize
endpoints) are always done over SSL.
* We enforce that every client must
supply the state parameter
(and our guidelines say they must verify
the state for CSRF
mitigation).
* We enforce that every client must
register a redirect URI.
* We validate the redirect_uri used to
request an access token is
the same that was used to obtain the
auth code.
* The only time a request is not made
over SSL is the redirect
with the auth_code which is very
short-lived (30 seconds) and is
tied to a verified redirect URI.
* We enforce that access tokens must be
provided using the
Authorization header only (and of
course, over SSL).
* We have guidelines saying that all
mobile apps must use the
native browser (and not an embedded web UI).
Questions:
========
1. Given the above scenario, what use
are refresh tokens?
- Access tokens can not leak because
every request (to resource
and authz server) containing an access
token is done over SSL. We
control both the authz and resource
servers, so tokens in logs
(and other suggested reasons in the
archives) are not an issue.
- Long-lived refresh tokens and
short-lived access tokens are
supposed to provide security due to
possible access token
leakage... but in our 100% SSL scenario,
if access tokens are
able to leak, then so would the client
id, secret and refresh
token.
- Having a long-lived refresh token that
can be exchanged for
another access token adds a level of
complexity (a second HTTPS
request every so often) and seems to
provide no benefit for our
case.
2. What is the point of the client
secret (in our scenario)? -
We originally were treating the clients
as confidential, but
after re-reading the native-application
section, it seems we
really should treat them as public
(phone apps can be decompiled
and the secret discovered).
- The spec says that the authz server
should authenticate
confidential clients, but public clients
are allowed to just send
their public client id (and no secret).
- The only verification then, is to
enforce redirect URI
registration and to validate the
redirect URI between
authorization and token steps.
So, the question is, assuming that we,
one: "enforce
redirect-URI registration" and two:
"validate that URI" - why
can't we treat all clients as public and
not worry about a
secret?
What is the benefit of having
confidential clients (and a secret)
at all?
Our API source is not available, but the
oauth2 server
implementation can be seen here:
https://github.com/quizlet/oauth2-php [4]
Regards,
Dave
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org> [5]
https://www.ietf.org/mailman/listinfo/oauth
[6]
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org> [7]
https://www.ietf.org/mailman/listinfo/oauth
[8]
Links:
------
[1] mailto:da...@quizlet.com <mailto:da...@quizlet.com>
[2] mailto:oauth@ietf.org <mailto:oauth@ietf.org>
[3] mailto:devt...@quizlet.com <mailto:devt...@quizlet.com>
[4] https://github.com/quizlet/oauth2-php
[5] mailto:OAuth@ietf.org <mailto:OAuth@ietf.org>
[6] https://www.ietf.org/mailman/listinfo/oauth
[7] mailto:OAuth@ietf.org <mailto:OAuth@ietf.org>
[8] https://www.ietf.org/mailman/listinfo/oauth
[9] mailto:wmi...@yahoo-inc.com <mailto:wmi...@yahoo-inc.com>
[10] mailto:phil.h...@oracle.com <mailto:phil.h...@oracle.com>
[11] http://www.independentid.com
[12] mailto:phil.h...@oracle.com <mailto:phil.h...@oracle.com>
[13] mailto:phil.h...@oracle.com <mailto:phil.h...@oracle.com>
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
