Re: [OAUTH-WG] OAuth2 Implementation questions (client secret andrefresh tokens)
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 Lodderstedttors...@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
Re: [OAUTH-WG] Reviewing draft-ietf-oauth-v2-21
I reviewed the diffs and it looks ok. regards, Torsten. Am 07.09.2011 17:59, schrieb Barry Leiba: As you've all probably seen, Eran has posted version 21 of the OAuth base spec, in which he believes he's addressed all comments and issues that came up in the review of version 20. We should be ready to send this to the IESG. Everyone who had comments or issues, please review -21 and make sure that your concerns have been handled to your satisfaction (or that there was no consensus to make a change). And we encourage everyone to review the changes from -20 to -21, to make sure Eran didn't inadvertently break anything along the way. The -21 is here: http://tools.ietf.org/html/draft-ietf-oauth-v2-21 And diffs from -20 can be found here: http://tools.ietf.org/rfcdiff?url2=draft-ietf-oauth-v2-21.txt We'll give it until the end of next week, while I work on the shepherd writeup. Comments, please, by 16 September. A few affirmative notes saying, Yes, I reviewed it and it looks good, will also be helpful. Keep in mind, as you review, that pet changes are out of scope at this point. We're just reviewing -21 to make sure (1) it doesn't break anything from -20, and (2) it isn't missing anything that was brought up in WGLC. New issues will have to be very serious, indeed, in order to be considered now. Also, a note on the thread that Mike Thomas started about the OAuth problem statement and threats: I did encourage him to start the discussion, and I think it can be a useful conversation. I do NOT think it will or should result in a change to the base spec, but it might feed into the threat model document (draft-ietf-oauth-v2-threatmodel), as Torsten, et al, move that toward completion. Remember that the base spec encourages readers to refer to the threat model document for more detailed descriptions of threats and attacks. Barry, as chair ___ 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
[OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-revocation-03.txt
Hi all, I just published a new revision of the token revocation draft. We added JSONP support (thanks to Marius) and aligned the text with draft 21 of the core spec. We would like to bring this draft forward as working group item (once the WG is ready). We think its relevance is illustrated by the fact that this draft (or its predecessor) has already been implemented by Google, Salesforce, and Deutsche Telekom. regards, Torsten. Original-Nachricht Betreff: New Version Notification for draft-lodderstedt-oauth-revocation-03.txt Datum: Fri, 16 Sep 2011 12:20:14 -0700 Von:internet-dra...@ietf.org An: tors...@lodderstedt.net CC: sdro...@gmx.de, tors...@lodderstedt.net, mscurte...@google.com A new version of I-D, draft-lodderstedt-oauth-revocation-03.txt has been successfully submitted by Torsten Lodderstedt and posted to the IETF repository. Filename:draft-lodderstedt-oauth-revocation Revision:03 Title: Token Revocation Creation date: 2011-09-16 WG ID: Individual Submission Number of pages: 6 Abstract: This draft proposes an additional endpoint for OAuth authorization servers for revoking tokens. The IETF Secretariat ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Reviewing draft-ietf-oauth-v2-21
Agreed. Phil On 2011-09-16, at 12:08, Torsten Lodderstedt tors...@lodderstedt.net wrote: I reviewed the diffs and it looks ok. regards, Torsten. Am 07.09.2011 17:59, schrieb Barry Leiba: As you've all probably seen, Eran has posted version 21 of the OAuth base spec, in which he believes he's addressed all comments and issues that came up in the review of version 20. We should be ready to send this to the IESG. Everyone who had comments or issues, please review -21 and make sure that your concerns have been handled to your satisfaction (or that there was no consensus to make a change). And we encourage everyone to review the changes from -20 to -21, to make sure Eran didn't inadvertently break anything along the way. The -21 is here: http://tools.ietf.org/html/draft-ietf-oauth-v2-21 And diffs from -20 can be found here: http://tools.ietf.org/rfcdiff?url2=draft-ietf-oauth-v2-21.txt We'll give it until the end of next week, while I work on the shepherd writeup. Comments, please, by 16 September. A few affirmative notes saying, Yes, I reviewed it and it looks good, will also be helpful. Keep in mind, as you review, that pet changes are out of scope at this point. We're just reviewing -21 to make sure (1) it doesn't break anything from -20, and (2) it isn't missing anything that was brought up in WGLC. New issues will have to be very serious, indeed, in order to be considered now. Also, a note on the thread that Mike Thomas started about the OAuth problem statement and threats: I did encourage him to start the discussion, and I think it can be a useful conversation. I do NOT think it will or should result in a change to the base spec, but it might feed into the threat model document (draft-ietf-oauth-v2-threatmodel), as Torsten, et al, move that toward completion. Remember that the base spec encourages readers to refer to the threat model document for more detailed descriptions of threats and attacks. Barry, as chair ___ 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 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-revocation-03.txt
If it's not already implicit by our implementation, I'm voicing our support for this becoming a working group item. - cmort On Sep 16, 2011, at 12:31 PM, Torsten Lodderstedt tors...@lodderstedt.netmailto:tors...@lodderstedt.net wrote: Hi all, I just published a new revision of the token revocation draft. We added JSONP support (thanks to Marius) and aligned the text with draft 21 of the core spec. We would like to bring this draft forward as working group item (once the WG is ready). We think its relevance is illustrated by the fact that this draft (or its predecessor) has already been implemented by Google, Salesforce, and Deutsche Telekom. regards, Torsten. Original-Nachricht Betreff:New Version Notification for draft-lodderstedt-oauth-revocation-03.txt Datum: Fri, 16 Sep 2011 12:20:14 -0700 Von:mailto:internet-dra...@ietf.org internet-dra...@ietf.orgmailto:internet-dra...@ietf.org An: mailto:tors...@lodderstedt.net tors...@lodderstedt.netmailto:tors...@lodderstedt.net CC: mailto:sdro...@gmx.de sdro...@gmx.demailto:sdro...@gmx.de, mailto:tors...@lodderstedt.net tors...@lodderstedt.netmailto:tors...@lodderstedt.net, mailto:mscurte...@google.com mscurte...@google.commailto:mscurte...@google.com A new version of I-D, draft-lodderstedt-oauth-revocation-03.txt has been successfully submitted by Torsten Lodderstedt and posted to the IETF repository. Filename:draft-lodderstedt-oauth-revocation Revision:03 Title: Token Revocation Creation date: 2011-09-16 WG ID: Individual Submission Number of pages: 6 Abstract: This draft proposes an additional endpoint for OAuth authorization servers for revoking tokens. The IETF Secretariat ___ OAuth mailing list OAuth@ietf.orgmailto:OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
