Re: [OAUTH-WG] delete access tokens?
Hi Bart, I think this would be a truly RESTful approach. The group discussed this topic several months ago and consensus was to use another endpoint for token revocation (== deletion). Pls. take a look onto http://tools.ietf.org/html/draft-lodderstedt-oauth-revocation-02. regards, Torsten. Von: Bart Wiegmans [mailto:b...@all4students.nl] Gesendet: Dienstag, 29. November 2011 11:32 An: oauth WG Betreff: [OAUTH-WG] delete access tokens? Hello everybody, again. This is just me pushing a random idea, but what if you specified that clients could ask for access token invalidation by making a DELETE request to the token endpoint? Bart Wiegmans ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Authorization Code Leakage feedback (Yaron Goland)
The security document designates it as Authorization code leakage through counterfeit client http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-00#section-4.4.1.7 Von: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Gesendet: Donnerstag, 18. August 2011 08:06 An: Lodderstedt, Torsten; OAuth WG Betreff: RE: Authorization Code Leakage feedback (Yaron Goland) I think using phishing here is misleading. This is not a classic phishing attack. I'm open to other suggestions. EHL From: Lodderstedt, Torsten [mailto:t.lodderst...@telekom.de] Sent: Wednesday, August 17, 2011 3:22 AM To: Eran Hammer-Lahav; OAuth WG Subject: AW: Authorization Code Leakage feedback (Yaron Goland) Text sounds very good. wrt title: this threat is about phishing another user's authorization code. Because of the design of the protocol this requires the attacker to use another redirect URI than used by the legitimate client. To make this the title sound bit weird to me. Why not authorization code phishing? regards, Torsten. Von: Eran Hammer-Lahav [mailto:e...@hueniverse.com]mailto:[mailto:e...@hueniverse.com] Gesendet: Mittwoch, 17. August 2011 08:39 An: OAuth WG Betreff: [OAUTH-WG] Authorization Code Leakage feedback (Yaron Goland) 10.6. Authorization Code Leakage: Comment I fancy myself as being reasonably intelligent and I'm unclear what attack is actually being described here. Yeah... I had to go back to -16 to be reminded of the section original title 'session fixation attack' to figure out what this was about. How about this: 10.6. Authorization Code Redirection URI Manipulation When requesting authorization using the authorization code grant type, the client can specify a redirection URI via the redirect_uri parameter. If an attacker can manipulate the value of the redirection URI, it can cause the authorization server to redirect the resource owner user-agent to a URI under the control of the attacker with the authorization code. An attacker can create an account at a legitimate client and initiate the authorization flow. When the attacker is sent to the authorization server to grant access, the attacker grabs the authorization URI provided by the legitimate client, and replaces the client's redirection URI with a URI under the control of the attacker. The attacker then tricks the victim into following the manipulated link to authorize access to the legitimate client. Once at the authorization server, the victim is prompted with a normal, valid request on behalf of a legitimate and familiar client, and authorizes the request. The victim is then redirected to an endpoint under the control of the attacker with the authorization code. The attacker completes the authorization flow by sending the authorization code to the client using the original redirection URI provided by the client. The client exchanges the authorization code with an access token and links it to the attacker's client account which can now gain access to the protected resources authorized by the victim (via the client). In order to prevent such an attack, the authorization server MUST ensure that the redirection URI used to obtain the authorization code, is the same as the redirection URI provided when exchanging the authorization code for an access token. The authorization server SHOULD require the client to register their redirection URI and if provided, MUST validate the redirection URI received in the authorization request against the registered value. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Authorization Code Leakage feedback (Yaron Goland)
In my opinion, the counterfeit redirection endpoint is another client - the counterfeit client. The attacker must trick the victim into accessing this client and approving the authorization request. So I would assume the attacker would try to let his endpoint look like the real client. Von: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Gesendet: Donnerstag, 18. August 2011 09:17 An: Lodderstedt, Torsten; OAuth WG Betreff: RE: Authorization Code Leakage feedback (Yaron Goland) But it's not really a counterfeit client but a real client with modified redirection uri. It is a counterfeit redirection endpoint. *I* understand exactly what you mean, but I fear new readers will get completely confused by the title. EHL From: Lodderstedt, Torsten [mailto:t.lodderst...@telekom.de] Sent: Thursday, August 18, 2011 12:12 AM To: Eran Hammer-Lahav; OAuth WG Subject: AW: Authorization Code Leakage feedback (Yaron Goland) The security document designates it as Authorization code leakage through counterfeit client http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-00#section-4.4.1.7 Von: Eran Hammer-Lahav [mailto:e...@hueniverse.com]mailto:[mailto:e...@hueniverse.com] Gesendet: Donnerstag, 18. August 2011 08:06 An: Lodderstedt, Torsten; OAuth WG Betreff: RE: Authorization Code Leakage feedback (Yaron Goland) I think using phishing here is misleading. This is not a classic phishing attack. I'm open to other suggestions. EHL From: Lodderstedt, Torsten [mailto:t.lodderst...@telekom.de]mailto:[mailto:t.lodderst...@telekom.de] Sent: Wednesday, August 17, 2011 3:22 AM To: Eran Hammer-Lahav; OAuth WG Subject: AW: Authorization Code Leakage feedback (Yaron Goland) Text sounds very good. wrt title: this threat is about phishing another user's authorization code. Because of the design of the protocol this requires the attacker to use another redirect URI than used by the legitimate client. To make this the title sound bit weird to me. Why not authorization code phishing? regards, Torsten. Von: Eran Hammer-Lahav [mailto:e...@hueniverse.com]mailto:[mailto:e...@hueniverse.com] Gesendet: Mittwoch, 17. August 2011 08:39 An: OAuth WG Betreff: [OAUTH-WG] Authorization Code Leakage feedback (Yaron Goland) 10.6. Authorization Code Leakage: Comment I fancy myself as being reasonably intelligent and I'm unclear what attack is actually being described here. Yeah... I had to go back to -16 to be reminded of the section original title 'session fixation attack' to figure out what this was about. How about this: 10.6. Authorization Code Redirection URI Manipulation When requesting authorization using the authorization code grant type, the client can specify a redirection URI via the redirect_uri parameter. If an attacker can manipulate the value of the redirection URI, it can cause the authorization server to redirect the resource owner user-agent to a URI under the control of the attacker with the authorization code. An attacker can create an account at a legitimate client and initiate the authorization flow. When the attacker is sent to the authorization server to grant access, the attacker grabs the authorization URI provided by the legitimate client, and replaces the client's redirection URI with a URI under the control of the attacker. The attacker then tricks the victim into following the manipulated link to authorize access to the legitimate client. Once at the authorization server, the victim is prompted with a normal, valid request on behalf of a legitimate and familiar client, and authorizes the request. The victim is then redirected to an endpoint under the control of the attacker with the authorization code. The attacker completes the authorization flow by sending the authorization code to the client using the original redirection URI provided by the client. The client exchanges the authorization code with an access token and links it to the attacker's client account which can now gain access to the protected resources authorized by the victim (via the client). In order to prevent such an attack, the authorization server MUST ensure that the redirection URI used to obtain the authorization code, is the same as the redirection URI provided when exchanging the authorization code for an access token. The authorization server SHOULD require the client to register their redirection URI and if provided, MUST validate the redirection URI received in the authorization request against the registered value. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Draft 20 last call comments
1.3/1.4/1.5: Consider switching order to Authorization Grant, Access Token, Refresh Token Not sure. What do others think? I put access token first because it is a more important term to get out of the way. I would rather consider to change order to Access Token, Refresh Token, Authorization Grant since the first two are the core OAuth concepts developers must become familiar with. Authorization grants are just an mean to an end to get the token for certain client types. Moreover, I expect the number of authorization grants to increase over time. 2.3: Should ... cannot be used alone be made into a normative, as ... MUST NOT be used alone? I'm ok with that. Anyone else? +1 regards, Torsten. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OMA Liaison Has Arrived!
+1 -Ursprüngliche Nachricht- Von: Barry Leiba [mailto:barryle...@computer.org] Gesendet: Mittwoch, 17. August 2011 22:35 An: oauth@ietf.org Betreff: Re: [OAUTH-WG] OMA Liaison Has Arrived! I'm sorry for the delay in getting this written. Because of the delay, the working group has just a short time to review my proposed response, below. Everyone, please have a look at the answers I propose to send, and post any objections to this thread by the end of the day on Monday, 22 August. Hannes, please also check with the IAB in parallel, and make sure we can send this via Murray as soon as we've resolved any WG objections. Barry, as chair - The IETF OAuth working group thanks OMA ARC SEC for the liaison statement titled OAuth discovery and specification availability, dated 18 July 2011. The OMA liaison statement asks the OAuth working group to address five issues, and our answers are as follows: . Availability of the IETF OAuth specifications: especially [draft-ietf-oauth-v2] and [draft-ietf-oauth-v2-bearer], and also [draft-hammer-oauth-v2-mac-token], [draft-lodderstedt-oauth-revocation] and [draft-recordon-oauth-v2-ux]. Answer: The IETF cannot guarantee publication dates, but we can give some best-guess timeframes. As this writing, draft-ietf-oauth-v2 and draft-ietf-oauth-v2-bearer have completed Working Group last call and are undergoing their final revisions before being sent to the IESG. We expect the final versions of those documents to be in the RFC Editor queue around the end of September, though it could be later if issues come up in IETF-wide last call or during IESG evaluation. The draft-hammer-oauth-v2-mac-token document has been replaced by draft-ietf-oauth-v2-http-mac, which is a working group document. It is likely to be in the RFC Editor queue by the end of the year. The remaining two documents are not working group documents, and the working group can say nothing about their status. The OAuth working group intends to revise its charter in the November timeframe, and it's possible that one or both of those documents could be adopted by the working group at that time, and we could have further information about target publication dates then. . Availability of the OAuth Parameters Registry Answer: The draft-ietf-oauth-v2 document establishes the OAuth Parameters Registry (in section 11.2, as of draft version 20). The registry will be available when the RFC is published, which will be some time after the document goes into the RFC Editor queue, depending upon the RFC Editor's load at the time. . IETF intent to specify an OAuth Discovery mechanism Answer: There is interest among OAuth working group participants for specifying such a mechanism, but the work is not in the current charter. It will likely be considered during the aforementioned charter update in (approximately) November. . Considerations that can help implementors decide about the type of OAuth access token to deploy. Answer: There is no current work planned, but documents with such implementation advice might also be considered during the rechartering discussion. . For bearer tokens: clarification whether the non-support of percent encoding for scope-v element of WWW-Authenticate Response Header Field grammar is intentional. Answer: In the bearer token document (Section 2.4 of draft-ietf-oauth-v2-bearer-08, The WWW-Authenticate Response Header Field), the scope-v element is unambiguously defined to allow a specific set of characters. That set of characters does permit, but does not mandate, support for percent-encoding of characters. - ___ 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] Draft 20 last call comment (Resource Owner Impersonation)
I've read the thread leading to this, and the proposed text and I do not understand the attack. Can you provide a step-by-step scenario of how an attacker gains access? I'm honestly surprised you do not understand the attack. The client simply uses screen scraping on the authorization flow and programmatically presses the right buttons. This obviously only works if the client can predict the form structure and expected input values. Also, it is unlikely that any major provider is going to require CAPCHA as part of the authorization flow. This is especially true in the case of using OAuth for login which has to be practically transparent (one click). I would hate to recommend a solution that no one is going to take seriously. This text has been proposed by 2 WG members (Niv and me), and reviewed by 3 others (Phil, Tony, Barry) and all agree with it. What is the foundation of your strong assessment? The text proposes three classes of countermeasures (detect source, prevent using unpredictable input, inform resource owner and give her a chance to revoke). CAPTCHAs are one out of three examples given for unpredictable input. So I don't understand why your objection focuses on it. The selection of the appropriate countermeasure is the task of the service provider and it will most likely depend this on its capabilities, cost, user experience, and risk/impact associated with abuse. CAPTCHAs (and even one time passwords) might not be the choice for the average internet service. This will be completely different if OAuth is used to process payment transactions. I'm keeping this proposed text out until we resolve this questions. See above - I probably misunderstand the IETF process, but several people agreed with it and no one (except you) objected. Why do you hold it back? regards, Torsten. EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt Sent: Friday, August 12, 2011 7:56 AM To: oauth@ietf.org Subject: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Hi all, I think the impersonation issue as raised by Niv on the list should be covered by the core spec. It directly aims at the trustworthiness of the user consent, which in my opinion is one of the core principles of OAuth. I therefore suggest to add a description to section 10. Please find below the text Niv and I prepared. In comparison to Niv's original proposal, it covers resource owner impersonation for all client categories. regards, Torsten. proposed text: 10.to be determined Resource Owner Impersonation When a client requests access to protected resources, the authorization flow normally involves the resource owner's explicit response to the access request, either granting or denying access to the protected resources. A malicious client can exploit knowledge of the structure of this flow in order to gain authorization without the resource owner's consent, by transmitting the necessary requests programmatically, and simulating the flow against the authorization server. An suthorization server will be vulnerable to this threat, if it uses non-interactive authentication mechanisms or split the authorization flow across multiple pages. It is RECOMMENDED that the authorization server takes measures to ensure that the authorization flow cannot be simulated. Attacks performed by scripts running within a trusted user-agent can be detected by verifying the source of the request using HTTP referrer headers. In order to prevent such an attack, the authorization server may force a user interaction based on non-predictable input values as part of the user consent approval. The authorization server could combine password authentication and user consent in a single form, make use of CAPTCHAs or one-time secrets. Alternatively, the authorization server could notify the resource owner of any approval by appropriate means, e.g. text message or e-Mail. ___ 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] Partial set of last call comments on OAuth draft 20 from Yaron Goland
1.4.3. Resource Owner Password Credentials: Comment on (when combined with a refresh token): This is the first time that refresh tokens are mentioned in the spec. And yet there is no explanation of what they are. I suspect they should anyway be introduced in section 1.4.1 (as previously noted) and then their use here will make sense. If that isn't possible then it would be good to have a forward reference to section 1.5 below so the reader has some idea of what's going on. I removed '(when combined with a refresh token)'. This is actually not true as there is no assumption that access tokens are always short-lived or that refresh tokens will always be issued to native applications using this grant type. -1 against removing this text (w/o an suitable replacement) and w/o group consent. The -20 text clearly points out that this combination ... eliminates the need for the client to store the resource owner credentials for future use. The resource owner grant type alone does not justify this statement. It's true that the spec does not explicitly defines the lifetime assumption for access and refresh tokens (which is pity in my opinion). So at least add something like if the token lifetime is reasonable long enough. regards, Torsten. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Authorization Code Leakage feedback (Yaron Goland)
Text sounds very good. wrt title: this threat is about phishing another user's authorization code. Because of the design of the protocol this requires the attacker to use another redirect URI than used by the legitimate client. To make this the title sound bit weird to me. Why not authorization code phishing? regards, Torsten. Von: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Gesendet: Mittwoch, 17. August 2011 08:39 An: OAuth WG Betreff: [OAUTH-WG] Authorization Code Leakage feedback (Yaron Goland) 10.6. Authorization Code Leakage: Comment I fancy myself as being reasonably intelligent and I'm unclear what attack is actually being described here. Yeah... I had to go back to -16 to be reminded of the section original title 'session fixation attack' to figure out what this was about. How about this: 10.6. Authorization Code Redirection URI Manipulation When requesting authorization using the authorization code grant type, the client can specify a redirection URI via the redirect_uri parameter. If an attacker can manipulate the value of the redirection URI, it can cause the authorization server to redirect the resource owner user-agent to a URI under the control of the attacker with the authorization code. An attacker can create an account at a legitimate client and initiate the authorization flow. When the attacker is sent to the authorization server to grant access, the attacker grabs the authorization URI provided by the legitimate client, and replaces the client's redirection URI with a URI under the control of the attacker. The attacker then tricks the victim into following the manipulated link to authorize access to the legitimate client. Once at the authorization server, the victim is prompted with a normal, valid request on behalf of a legitimate and familiar client, and authorizes the request. The victim is then redirected to an endpoint under the control of the attacker with the authorization code. The attacker completes the authorization flow by sending the authorization code to the client using the original redirection URI provided by the client. The client exchanges the authorization code with an access token and links it to the attacker's client account which can now gain access to the protected resources authorized by the victim (via the client). In order to prevent such an attack, the authorization server MUST ensure that the redirection URI used to obtain the authorization code, is the same as the redirection URI provided when exchanging the authorization code for an access token. The authorization server SHOULD require the client to register their redirection URI and if provided, MUST validate the redirection URI received in the authorization request against the registered value. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Request to close issues
What about my comments? http://www.ietf.org/mail-archive/web/oauth/current/msg07030.html http://www.ietf.org/mail-archive/web/oauth/current/msg07031.html http://www.ietf.org/mail-archive/web/oauth/current/msg07032.html -Ursprüngliche Nachricht- Von: Barry Leiba [mailto:barryle...@computer.org] Gesendet: Freitag, 22. Juli 2011 16:03 An: Eran Hammer-Lahav Cc: OAuth WG Betreff: Re: [OAUTH-WG] Request to close issues I would like to ask the chairs to close the following issues: #15 section 2 #16 section 3.1.2 #17 section 3.2.1 Having seen no objection to this, I will close these three as fixed now. 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
Re: [OAUTH-WG] Resource Owner Password Credentials question/feedback
No exactly the topic but also related to this grant type There is currently no parameter the client could use to explicitly request a refresh token. So server-policies based on user, client and scope are the only mean to decide whether a refresh token is issued or not. I consider this to limited as there might be the desire this control this per authorization process, i.e. I client could ask the user whether he/she wants to stay connected or stay logged in. A parameter to pass this information to the authz server would be useful. regards, Torsten. Von: George Fletcher [mailto:gffle...@aol.com] Gesendet: Dienstag, 28. Juni 2011 17:47 An: oauth@ietf.org Betreff: [OAUTH-WG] Resource Owner Password Credentials question/feedback I'm working on spec'ing out a use of the Resource Owner Password Credentials flow and in trying to map out possible error cases, realized that there is no good error for the case that the resource owner's password credentials are invalid. Section 4.3 of draft 16 references section 5.2 for errors. The list of available errors in section 5.2 are... error REQUIRED. A single error code from the following: invalid_request The request is missing a required parameter, includes an unsupported parameter or parameter value, repeats a parameter, includes multiple credentials, utilizes more than one mechanism for authenticating the client, or is otherwise malformed. invalid_client Client authentication failed (e.g. unknown client, no client credentials included, multiple client credentials included, or unsupported credentials type). The authorization server MAY return an HTTP 401 (Unauthorized) status code to indicate which HTTP authentication schemes are supported. If the client attempted to authenticate via the Authorization request header field, the authorization server MUST respond with an HTTP 401 (Unauthorized) status code, and include the WWW-Authenticate response header field matching the authentication scheme used by the client. invalid_grant The provided authorization grant is invalid, expired, revoked, does not match the redirection URI used in the authorization request, or was issued to another client. unauthorized_client The authenticated client is not authorized to use this authorization grant type. unsupported_grant_type The authorization grant type is not supported by the authorization server. invalid_scope The requested scope is invalid, unknown, malformed, or exceeds the scope granted by the resource owner. I'm wondering if others have chosen one of these values to represent the invalid_credentials use case. Thanks, George ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Resource Owner Password Credentials question/feedback
Issuing a refresh token is more a function of the access grant duration than anything else. Agreed. How shall the user influence this duration? There is no direct interaction between authz server and end-user. The client can always throw away tokens when it is done of if the user doesn't want to stay connected, but issuing long term credentials is not really something the client asks but the server decides (based on user approval and policy). This is a waste of resources. Moreover, how do you explain the end-user if a long-term authorization shows up in his service providers account management screen for a certain client he never explicitly authorized for long-term access? regards, Torsten. Von: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Gesendet: Donnerstag, 30. Juni 2011 10:48 An: Lodderstedt, Torsten; George Fletcher; oauth@ietf.org Betreff: RE: [OAUTH-WG] Resource Owner Password Credentials question/feedback Issuing a refresh token is more a function of the access grant duration than anything else. The client can always throw away tokens when it is done of if the user doesn't want to stay connected, but issuing long term credentials is not really something the client asks but the server decides (based on user approval and policy). EHL From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Lodderstedt, Torsten Sent: Thursday, June 30, 2011 1:10 AM To: George Fletcher; oauth@ietf.org Subject: Re: [OAUTH-WG] Resource Owner Password Credentials question/feedback No exactly the topic but also related to this grant type There is currently no parameter the client could use to explicitly request a refresh token. So server-policies based on user, client and scope are the only mean to decide whether a refresh token is issued or not. I consider this to limited as there might be the desire this control this per authorization process, i.e. I client could ask the user whether he/she wants to stay connected or stay logged in. A parameter to pass this information to the authz server would be useful. regards, Torsten. Von: George Fletcher [mailto:gffle...@aol.com]mailto:[mailto:gffle...@aol.com] Gesendet: Dienstag, 28. Juni 2011 17:47 An: oauth@ietf.orgmailto:oauth@ietf.org Betreff: [OAUTH-WG] Resource Owner Password Credentials question/feedback I'm working on spec'ing out a use of the Resource Owner Password Credentials flow and in trying to map out possible error cases, realized that there is no good error for the case that the resource owner's password credentials are invalid. Section 4.3 of draft 16 references section 5.2 for errors. The list of available errors in section 5.2 are... error REQUIRED. A single error code from the following: invalid_request The request is missing a required parameter, includes an unsupported parameter or parameter value, repeats a parameter, includes multiple credentials, utilizes more than one mechanism for authenticating the client, or is otherwise malformed. invalid_client Client authentication failed (e.g. unknown client, no client credentials included, multiple client credentials included, or unsupported credentials type). The authorization server MAY return an HTTP 401 (Unauthorized) status code to indicate which HTTP authentication schemes are supported. If the client attempted to authenticate via the Authorization request header field, the authorization server MUST respond with an HTTP 401 (Unauthorized) status code, and include the WWW-Authenticate response header field matching the authentication scheme used by the client. invalid_grant The provided authorization grant is invalid, expired, revoked, does not match the redirection URI used in the authorization request, or was issued to another client. unauthorized_client The authenticated client is not authorized to use this authorization grant type. unsupported_grant_type The authorization grant type is not supported by the authorization server. invalid_scope The requested scope is invalid, unknown, malformed, or exceeds the scope granted by the resource owner. I'm wondering if others have chosen one of these values to represent the invalid_credentials use case. Thanks, George ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Draft 16 comment
+1 for (1) As pointed out in another posting (http://www.ietf.org/mail-archive/web/oauth/current/msg06723.html), I think we have consensus on the patterns for native app implementation. So in my opinion, we need to adjust the client authentication part to fit. In my opinion, the authz server cannot prevent a client from using another clients id, even pre-registering a redirect_uri won't help. But this only means, the authz server cannot provide the user with trustworthy data regarding the app. In this case it is the task of the user and the platform the app is running on to detect malicious clients (maleware, viruses). regards, Torsten. -Ursprüngliche Nachricht- Von: Mark Mcgloin [mailto:mark.mcgl...@ie.ibm.com] Gesendet: Dienstag, 28. Juni 2011 12:26 An: Shane B Weeden Cc: oauth@ietf.org; oauth-boun...@ietf.org Betreff: Re: [OAUTH-WG] Draft 16 comment The question below remains unanswered in relation to native apps being able to use grant type auth code to utilize refresh tokens. Which of these is the best option 1) Change oauth spec so client credentials are optional when requesting access token for grant type 'authorization_code' and for refresh token requests 2) Edit section 9 on security considerations to remove any references to native apps using auth code The difficulty with option 1 is how do you then prevent attackers using a legitimate client identifier. If we change the spec to say the client SHOULD pre-register it's redirect-uri, would that suffice? Regards Mark oauth-boun...@ietf.org wrote on 23/05/2011 05:40:22: From: Shane B Weeden swee...@au1.ibm.com To: oauth@ietf.org Date: 23/05/2011 06:26 Subject: [OAUTH-WG] Draft 16 comment Sent by: oauth-boun...@ietf.org First, I'd like to add my support for Brian Eaton's comments on Draft 16. They actually helped clarify the comment I have below I found section 9 to be in contradiction to a part of section 6. In particular in section 9: Native applications SHOULD use the authorization code grant type flow without client password credentials (due to their inability to keep the credentials confidential) to obtain short-lived access tokens, and use refresh tokens to maintain access. In section 6 the specification is quite clear that client authentication is REQUIRED for the use of refresh tokens: The authorization server MUST validate the client credentials, ensure that the refresh token was issued to the authenticated client, validate the refresh token, and verify that the resource owner's authorization is still valid. My understanding is that refresh tokens are being used as a kind of long-lived, rolling instance secret for the native application and represent the grant authorized by the end user during initial establishment of the authorization code which is used to get the first refresh token. It seems to me this use case needs to be allowed for in the wording of section 6. Regards, Shane. ___ 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] consistency of token param name in bearer token type
The reason why I suggested the name bearer_token was to achieve a consistent naming convention across different ways to uses those tokens (URI query, HTTP authn scheme). Now the discussion centers around achieving a consistent naming between token acquisition and usage. I'm basically fine with reverting to access_token. Just one question: Is the assumption of the group that bearer tokens are the only type of tokens to be used in conjunction with URI query parameters? Otherwise, a mechanism is needed to distinguish bearer and other tokens, e.g. another parameter (token_type?). Regards, Torsten. -Ursprüngliche Nachricht- Von: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Gesendet: Mittwoch, 15. Juni 2011 19:38 An: Mike Jones; David Recordon; George Fletcher Cc: paul Tarjan; oauth@ietf.org Betreff: Re: [OAUTH-WG] consistency of token param name in bearer token type It should be pretty easy :-) Anyone objects to changing the parameter name from 'bearer_token' to 'access_token'? Let Mike know by 6/20 or he will make the change. EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones Sent: Wednesday, June 01, 2011 1:15 PM To: David Recordon; George Fletcher Cc: paul Tarjan; oauth@ietf.org Subject: Re: [OAUTH-WG] consistency of token param name in bearer token type If you can drive a consensus decision for the name access_token, I'd be glad to change the name in the spec. I agree that the current names are confusing for developers. -- Mike -Original Message- From: David Recordon [mailto:record...@gmail.com] Sent: Wednesday, June 01, 2011 12:06 AM To: George Fletcher Cc: Mike Jones; Doug Tangren; oauth@ietf.org; paul Tarjan Subject: Re: [OAUTH-WG] consistency of token param name in bearer token type Yeah, can understand how we got here. Just found it quite confusing when reading these two specifications together with an implementor's hat on. On Tue, May 31, 2011 at 12:29 PM, George Fletcher gffle...@aol.com wrote: Brief pointer to the history of this change. This change was adopted in draft 4 of the bearer spec as there were concerns with the previous parameter name of 'oauth_token'. The suggestion was made to use 'bearer_token' so that it matches the scheme used in the Authorization header. The thinking being that reading the bearer token spec would seem weird if the Authorization header used one name and the GET/POST methods used a different name. The 'bearer_token' name got a few +1 and no dissents. Full thread starts here [1]. Mike accepting the 'bearer_token' recommendation is here [2]. Thanks, George [1] http://www.ietf.org/mail- archive/web/oauth/current/msg05497.html [2] http://www.ietf.org/mail- archive/web/oauth/current/msg05881.html On 5/28/11 12:30 PM, David Recordon wrote: Did a full read through of draft 16 and the bear token spec with Paul yesterday afternoon in order to do a manual diff from draft 10. The point Doug raised was actually confusing. Throughout the core spec it's referred to as access_token but then becomes bearer_token upon use. Just thinking through this from a developer documentation perspective, it's going to become confusing. Developer documentation focuses on getting an access token and then using that access token to interact with an API. Thus the code you're writing as a client developer will use variables, cache keys, and database columns named `access_token`. But then when you're going to use it, you'll need to put this access token into a field named bearer_token. Feels quite a bit simpler to just name it access_token. Realize the core spec never did this since we didn't want to trample on protected resources which might already have a different type of access_token parameter. oauth_token was a good compromise since developers would already know that they were using OAuth and thus a new term wasn't being introduced. That's no longer true with bearer_token since 99% of developers will have never heard of a bearer token. Googling for bearer token turns up Eran's blog post titled OAuth Bearer Tokens are a Terrible Idea and there isn't a single result on the first page which explains what they are. Binging for bearer token is equally scary. --David On Mon, May 23, 2011 at 11:38 AM, Mike Jones michael.jo...@microsoft.com wrote: The working group explicitly decided that a different name should be used, to make it clear that other token types other than bearer tokens could also be used with OAuth 2. -- Mike From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Doug Tangren Sent: Wednesday,
Re: [OAUTH-WG] Refresh tokens
+1 Von: Brian Eaton [mailto:bea...@google.com] Gesendet: Mittwoch, 15. Juni 2011 20:33 An: Eran Hammer-Lahav Cc: OAuth WG Betreff: Re: [OAUTH-WG] Refresh tokens On Wed, Jun 15, 2011 at 10:30 AM, Eran Hammer-Lahav e...@hueniverse.commailto:e...@hueniverse.com wrote: I would like to add a quick discussion of access token and refresh token recommended deployment setup, providing clear guidelines when a refresh token SHOULD and SHOULD NOT be issued, and when issues, how it is difference from the access token. Is this a start? http://www.ietf.org/mail-archive/web/oauth/current/msg06362.html It's time we stop trying to accommodate every possible combination and make some hard choices. +1. Yes please. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16
The ability to describe a client to the user does not depend on the authentication but on the identification of the client and the meta data available to the authz server. The only difference between identified and authenticated clients is the trust level the authz server has regarding the client's identity. It must clearly indicate this fact to the end-user. regards, Torsten. Von: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Gesendet: Mittwoch, 15. Juni 2011 21:20 An: Torsten Lodderstedt; Brian Eaton Cc: OAuth WG Betreff: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16 I agree to the extent that the user can be trusted to know how they got to the authorization endpoint. If the client cannot be authenticated, the authorization server is limited in the information it can offer the user to make the decision. It is extremely hard to come up with language that will tell the user to only approve the application, claiming to be X, if they got here from X directly. There might be ways to improve security a bit using Origin header etc. but overall, if the client is not authenticated, the authorization server can't really describe it to the user. EHL From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt Sent: Thursday, June 02, 2011 2:10 AM To: Brian Eaton Cc: OAuth WG Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16 I fully agree with Brian and would like to add some thoughts: Not authenticating the client does not directly create a security problem at all. If we would follow this line, every e-Mail client out there would be considered insecure because the client itself is never authenticated. Not even Kerbereos has a concept of client authentication. In my opinion, OAuth client authentication (in delegated authorization scenarios) is an improvement over classical approaches. But I do not see a degration in security if it is not applicable. As long as the _user_ authorizes the client's access (and the duration of the token) and is able to revoke the tokens at any time, the situation is much better than with classical approaches. regards, Torsten. Am 01.06.2011 21:06, schrieb Brian Eaton: Hey Peter - I haven't read all of your comments yet, but I wanted to clarify one point about client impersonation and installed apps. The cuirrent text is unrealistic, but your request would push it the wrong way. CC'ing Torsten as well. - OLD: The authorization server SHOULD issue access tokens with limited scope and duration to clients incapable of authenticating. NEW: If the authorization server issues access tokens to clients that are incapable of authenticating, the scope and duration of such tokens SHOULD be limited. RATIONALE: We're not actively RECOMMENDING authorization servers are to issue such tokens, are we? - We are most definitely recommending that clients that have no way of authenticating are issued long-lived credentials to access user data. Most installed applications work as follows: - they ask the user for their password - they save the password to disk That's a horrible security problem, because it means you cannot upgrade user authentication to anything stronger than a password. Client certificates, one time passwords, risk based authentication, throw it all out the window. If you're going to let installed apps authenticate with just a password, nothing else you do to improve authentication is going to help. This is a blocking issue for rolling out stronger forms of user authentication, and it's one of the main reasons I care about OAuth2. Think IMAP and XMPP clients running on Windows desktops. They are important, and we need a way to migrate them off of saving passwords. So the current text basically says that you should issue temporary credentials to native apps. That's not practical. Native apps end up needing permanent or near-permanent credentials. Expirations need to be measured in months. And the credentials are going to be issued to stock IMAP and XMPP clients that don't have any way of authenticating themselves. The advantage with OAuth2 over passwords is that a) the refresh tokens are unguessable. b) the refresh tokens aren't sent directly to the IMAP and XMPP servers, they are restricted to authorization servers. c) if you've got a managed machine (think Kerberos logins), you can create flows that bridge from those managed credentials to temporary access credentials. Cheers, Brian ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Updated text for Native Apps
In my perception, the main concern raised at the F2F was the absent of the implicit grant in the text. That's what Chuck added including a discussion of the pros and cons. Most of the discussion in the thread you referred to was about refresh tokens support in the implicit grant type, which was caused by an additional question by Chuck. This would be a fundamental change to the protocol and we had a lively discussion about this idea. In the end, I have not seen a proposal to add this feature to the spec. This discussion is independent of the native apps text Chuck proposed (http://www.ietf.org/mail-archive/web/oauth/current/msg06444.html) and I have not seen any objection on this text. I therefore consider this a consensous. So please consider the proposed text for the next revision of the draft. regards, Torsten. Von: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Gesendet: Mittwoch, 15. Juni 2011 19:35 An: Anthony Nadalin; Chuck Mortimore; oauth@ietf.org Betreff: Re: [OAUTH-WG] Updated text for Native Apps That's an odd way of looking at it. I'm looking at over 30 responses to the text with clear disagreement on how native applications should be deployed using different grant types. To say that there is consensus to the text, but not to the other comments objecting to it is ignoring the lack of consensus... If you think you can propose a new text that will be endorsed by the group, please go ahead. But the F2F action item carries no weight if the list doesn't like what is suggested. What is clear from the discussion is that we have some unresolved issues around refresh tokens and client authentication which are at the heart of advising about native applications. It would be impossible to make recommendations without resolving these issues first (and once we do, I would argue no additional text would be needed). EHL From: Anthony Nadalin [mailto:tony...@microsoft.com] Sent: Wednesday, June 15, 2011 10:24 AM To: Eran Hammer-Lahav; Chuck Mortimore; oauth@ietf.org Subject: RE: Updated text for Native Apps Not seeing what you write about below, I think that the basic text that was discussed at the F2F has consensus around the guidance (with some changes that were discussed and Chuck provided), I think that some of the other thoughts people have thrown out don't. I disagree with dropping the text as there is not consensus to do that, since there was an action item to put text back in. From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Wednesday, June 15, 2011 10:19 AM To: Anthony Nadalin; Chuck Mortimore; oauth@ietf.org Subject: RE: Updated text for Native Apps This working group has failed, for well over a year, to reach any sort of consensus regarding which grant types are suitable for a given client type. There was no draft between 00 and 16 in which we had agreement on the definition of client types, or the exclusivity of any flow to any given type. Trying to reach such a conclusion is a waste of time. The main reason for this is lack of deployment experience. We have pretty good experience with some cases like a server-based client capable of keeping secrets, and browser-based clients executing fully visible source code. We clearly do not even have a clear definition of what is a native application and the recent attempt to define a native application client type seems to cause more confusion than help. While there is clearly an expectation that the specification will offer guidance to native application developers, I have yet to see any such text gaining consensus. My suggestion is to drop this attempt, but if a new text gain consensus, I'll incorporate it. EHL From: Anthony Nadalin [mailto:tony...@microsoft.com]mailto:[mailto:tony...@microsoft.com] Sent: Wednesday, June 15, 2011 10:10 AM To: Eran Hammer-Lahav; Chuck Mortimore; oauth@ietf.orgmailto:oauth@ietf.org Subject: RE: Updated text for Native Apps Since Torsten and I had the action item to propose text we will update the text based upon the list and give you back an update From: oauth-boun...@ietf.orgmailto:oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org]mailto:[mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Wednesday, June 15, 2011 9:33 AM To: Chuck Mortimore; oauth@ietf.orgmailto:oauth@ietf.org Subject: Re: [OAUTH-WG] Updated text for Native Apps Is there an updated text based on the long thread? EHL From: oauth-boun...@ietf.orgmailto:oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org]mailto:[mailto:oauth-boun...@ietf.org] On Behalf Of Chuck Mortimore Sent: Tuesday, May 31, 2011 10:37 AM To: oauth@ietf.orgmailto:oauth@ietf.org Subject: [OAUTH-WG] Updated text for Native Apps Minor updates for section 9 based upon feedback from the list -cmort 9. Native Applications A native application is a client which is installed and executes on the end-user's device (i.e. desktop application, native mobile application). Native
Re: [OAUTH-WG] oauth2 implicit flow user experience
How shall the authorization server ensure that the calling client is a user-agent based app (i.e. a native app could impersonate an user-agent based app)? In my opinion, enforcing explicit user consent is the only way to prevent this kind of attack. regards, Torsten. -Ursprüngliche Nachricht- Von: Marius Scurtescu [mailto:mscurte...@google.com] Gesendet: Mittwoch, 11. Mai 2011 20:28 An: Lodderstedt, Torsten Cc: oauth@ietf.org; Doug Tangren Betreff: Re: [OAUTH-WG] oauth2 implicit flow user experience On Tue, May 10, 2011 at 4:43 PM, Lodderstedt, Torsten t.lodderst...@telekom.de wrote: Hi Marius, wrt auto-approval: how is the authorization server supposed to validated the client's identity in a reliable way? Otherwise another application (using the id of the legitimate client) could abuse the authorization previously approved by the user as long as the session with the authorization server is valid. The redirect_uri won't help for all kinds of clients since a native app could use the correct redirect_uri and nevertheless get access to the token. The only validation is based on the redirect URI. Native apps should not use the implicit flow, and in general there is no need for auto-approval for them. Marius ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Fwd: OAuth Security Consideration Text
Hi Breno, thanks for the feedback. Please find my comments inline. Now higher level comments: On Native Apps protection of refresh token: On section Definitions, there is a sentence in the Native Apps It is assumed that such applications can protect dynamically issued secrets, such as refresh tokens, from eavesdropping by other applications residing in the same service the original text says: on the same device I suggest that you strike out this sentence from definitions since it is confusing. This should be moved to section 2.4, with a specific headed paragraph about management of refresh tokens for native applications including specific recommendation. This section shall document all assumptions determining the differences between those categories, which are relevant for the security sections. Thus I would like to keep it and probably improve it. E.g. of substitution paragraph: Native Applications MUST use operating system mediated protections to ensure that the refresh tokens are safe from unauthorized access by other users and applications. It is highly RECOMMENDED that such applications use OS-provided APIs to manage secrets. The applications MUST apply appropriately restrictive access controls to any file system or persistent memory objects where the refresh token is stored. On Client Authentication: Authorization servers are encouraged to consider stronger client authentication means -- This is too vague to be actionable. There is a great tradition of 'innovation' in client security that promotes no security and hinders interoperability. I tend to believe that it is better for servers to be conscious of the limitations of client authentication and implement mitigation measures than to create ad- hoc authentication mechanisms. Suggest to strike out this sentence. Authorization server MUST NOT issue client secrets to native or user agent-based applications in general. - Agreed on user-agent, however at least in principle it is possible to issue secrets to native applications that use hardware-based DRM modules and can hold on to secrets. A couple of comments on this: 1) This statement is intended to prohibit secrets for software packages and not software instances. Thus the text also says An authorization server MAY issue a client secret for an installation of a native application on a specific device.. We just want to get rid of the bad practice of using secrets for authenticating software packages. This practice creates a false feeling of security and people tend to rely on this kind of client authentication too much. They shall be adviced to utilize other means than client secrets. 2) The intention of the text is to give simple and clear rules instead of discussing if, then and why. This discussion is subject of the security threats and considerations I-D referenced by the introduction of the text. 3) DRM modules give you a device specific authentication, they do not authenticate a certain software package or instance. More importantly, since the OAuth2 spec no longer actually specifies how to implement a Native App Flow end-to-end, I am not sure how to even reason about Native App issues. Propose simply strike out 'native or'. The description of how to implement native apps is badly missing right now and has been requested during IETF-80. It will be re-included soon. On Malicious Client Obtains Authorization: Authorization servers MUST NOT automatically process (without user interaction) repeated authorizations without authenticating the client. - Not sure what to make of this sentence. If this implies User-Agent should not support automatic renewal of access tokens (since user-agent apps cannot be 'authenticated'), then it is a harmful recommendation because it ignores practical requirements. The bad word here is 'authenticating', since what is really intended is some assurance that it is the same client, e.g., the redirect URI matches a registered value in the User-Agent case. Please strike out this sentence or substitute it with one like: Authorization servers MUST implement measures to ensure that automatically issued tokens (without user interaction, based on previously recorded grant) are delivered to the same client to whom original grant was performed. Example of suitable measures are enforcing client authentication or enforcing that the destination of a redirect (in case of implicit grant) matches the expected value for the client. As discussed in the other thread. I do not consider the redirect_uri enforcement to be a reliable way to prevent abuse of existing authorizations. On Access Tokens Application developers MUST NOT store access tokens in non-transient memory. - This is not realistic -- consider the case of a Web Application running on distributed servers. It is quite possible that the only distributed
Re: [OAUTH-WG] oauth2 implicit flow user experience
Hi Marius, wrt auto-approval: how is the authorization server supposed to validated the client's identity in a reliable way? Otherwise another application (using the id of the legitimate client) could abuse the authorization previously approved by the user as long as the session with the authorization server is valid. The redirect_uri won't help for all kinds of clients since a native app could use the correct redirect_uri and nevertheless get access to the token. regards, Torsten. -Ursprüngliche Nachricht- Von: Marius Scurtescu [mailto:mscurte...@google.com] Gesendet: Dienstag, 10. Mai 2011 21:15 An: Doug Tangren Cc: oauth@ietf.org Betreff: Re: [OAUTH-WG] oauth2 implicit flow user experience On Tue, May 10, 2011 at 6:25 AM, Doug Tangren d.tang...@gmail.com wrote: Hi, I'm implementing an authorization and resource server at worked based on the oauth2 draft 15. A question arose about the user experience of users of an implicit client flow. I've set a one hour expiry on access tokens but now the question is should the client be forced to re-prompt the user for authorization when their receive an error response from the resource server or when they refresh the page? I realize that some implementation details like this are mentioned as being beyond the scope of the spec but I wanted to get a general sense of what the authors and implementors thoughts about how it would actually be used and what is the expected user experience. I also realize that from a server's perspective, without a client secret, authorization code, or other prior evidence of who a request is coming from that there is little way for a server to be permissive about allowing for the refreshing of an access token in an implicit flow. Has there been any conversation around possible alternatives that would permit users of the implicit flow to have the same user experience as the authorization code flow? This question was raised a few times on this list. The only solution I am aware of is for the authorization server to support auto-approvals and an immediate mode, Auto-approval means that the server will not show the approval page if the same user/scopes/client have already been approved. So as long as the user has an active session the client can get new access tokens in a hidden iframe. If the user session times out then the request in the iframe will hang, the frame will be redirected to a login page. To prevent this the client must be able to tell authorization server that it wants an immediate type request, no UI whatsoever should be shown and if auto-approval is not possible, or not active session, then just return an error. The client then can popup a window and start a regular request, so the user can login and/or approve. Auto-approvals are up to the server to support, no support from the protocol is required. You probably want to support this only for the implicit flow. Immediate mode needs a special request parameter and also a special error code. There is no extension that defines these, the suggestion was that this should go into the OpenID Connect spec, together with a username hint parameter. Hope this helps, Marius ___ 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
