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
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
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 p
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 ab
I agree, it is a matter of tradeoffs, but I think you have the idea.
As for your question in 3, think of rotation as following the same practice as
periodic re-authentication of browser based users. If you never do that, you
probably don't care to re-authenticate client apps either. But if you
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 ove
> ** **
>
> *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf
> Of *Phillip Hunt
> *Sent:* Wednesday, September 07, 2011 4:24 PM
> *To:* William Mills
> *Cc:* Quizlet Dev Team; oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] OAuth2 Implementa
See below...
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
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
> ** **
>
> *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf
> Of *Phillip Hunt
> *Sent:* Wednesday, September 07, 2011 4:24 PM
> *To:* William Mills
> *Cc:* Quizlet Dev Team; oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] OAuth2 Implementa
Hi Phil,
>> The client is then forced to periodically reauthenticate (without the
user) before getting a new access token.
What benefit does that have?
>> 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
Cc: Quizlet Dev Team; oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth2 Implementation questions (client secret and
refresh tokens)
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
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
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 iss
13 matches
Mail list logo
