Re: [OAUTH-WG] Fwd: OAuth Security Consideration Text
On Wed, May 11, 2011 at 7:23 PM, Lodderstedt, Torsten < t.lodderst...@telekom.de> wrote: > 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. > This may be a difference of opinion rather than substance, but I find that assumptions stated too far ahead of their use suffer from lack of connection. I would suggest again that the definition remain purely semantic, and the security assumptions be discussed more closely to the attending threats and mitigations. > > > > > > > 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. > When the spec did define a Native App flow it mandated the opposite (the secret was required not optional), which led Google, for instance, to launch the OAuth2 registration for clients to include secret issuance for native apps---against the recommendation of our internal security team---for pure compliance reasons (not that we are relying on its remaining a secret, our security model does not rely on this). I welcome the change of language (even if we may take some time for Google to catch up with it), but find it a bit too strong. Possibly "It is NOT RECOMMENDED ..." followed by some description of why this is ineffective as a security measure? > 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. > Yes, and I am not suggesting it should -- my recommendation was to strike it out. However, what about a softened approach as above? > 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. > That's welcome news indeed. > > > > > > > On Malicious Client Obtains Authorizati
Re: [OAUTH-WG] consistency of token param name in bearer token type
The name needs to be unique enough not to conflict with likely parameters already used by providers. I don’t have an opinion which name is better, just that it was oauth_token before and when we changed the scheme name to Bearer, changed it too. EHL From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Doug Tangren Sent: Wednesday, May 11, 2011 10:09 PM To: oauth@ietf.org Subject: [OAUTH-WG] consistency of token param name in bearer token type This may have come up before so I'm sorry if I'm repeating. Why does bearer token spec introduce a new name for oauth2 access tokens [1], "bearer_token", and before that [2], "oauth_token"? I apologize if this may sound shallow but, why introduce a new parameter name verses sticking with what the general oauth2 spec already defines, "access_token". It seems arbitrary for an auth server to hand a client an apple then have the client hand it off to the resource server and call it an orange. Was this just for the sake of differentiating the parameter name enough so that the bearer tokens may be used in other protocols without being confused with oauth2 access_tokens? [1]: http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-04#section-2.2 [2]: http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-03#section-2.2 -Doug Tangren http://lessis.me ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] consistency of token param name in bearer token type
This may have come up before so I'm sorry if I'm repeating. Why does bearer token spec introduce a new name for oauth2 access tokens [1], "bearer_token", and before that [2], "oauth_token"? I apologize if this may sound shallow but, why introduce a new parameter name verses sticking with what the general oauth2 spec already defines, "access_token". It seems arbitrary for an auth server to hand a client an apple then have the client hand it off to the resource server and call it an orange. Was this just for the sake of differentiating the parameter name enough so that the bearer tokens may be used in other protocols without being confused with oauth2 access_tokens? [1]: http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-04#section-2.2 [2]: http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-03#section-2.2 -Doug Tangren http://lessis.me ___ 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-trans
Re: [OAUTH-WG] BCP for returning HTTP Authentication (2617) Error Status (questions from the OAuth WG)
My .02 - On 10/05/2011, at 2:49 AM, Eran Hammer-Lahav wrote: > The OAuth working group has defined an authorization protocol [1] for > delegating access to protected resources. Once access has been authorized, > the client is issued a set of token credentials which are uses to make > authenticated HTTP requests. To accomplish that, the OAuth working group has > proposed two new HTTP authentication schemes: Bearer [2] and MAC [3]. > > The working group has been debating the issue of what's the best current > practice for returning an error status in an HTTP authentication scheme. The > Basic and Digest schemes do not specify the error condition and simply return > a 401 response with a new challenge. The MAC proposal follows this pattern. > > The Bearer scheme proposal is taking a more active approach, defining an > 'error' response attribute for use with the WWW-Authenticate header and an > error code registry to go along. The parameter and registry (especially the > registry) are meant for reuse by other HTTP authentication schemes. At the > moment, the three error conditions proposed by the Bearer draft are: invalid > request, invalid token, and insufficient scope (which arguably is better > suited using a 403 response with or without a new challenge). > > While these error codes arguably do not provide an immediate actionable value > (pending the help of future discovery specifications), the attribute and > registry propose a forward-looking solution for when clients will be able to > automatically resolve such issues (with the help of future discovery > specifications). > > The OAuth WG is seeking guidance on the following questions: > > 1. Should the WG define a general purpose method for returning errors with a > 401 WWW-Authenticate headers, including a cross-scheme error code registry? I don't have strong feelings about whether or not it's a good idea overall. However, I tend to think that if it's intended for more than one scheme, it'd make more sense to a) make it a separate header, much like Authentication-Info for successful responses, and b) also note that it's a good idea to put human-friendly information in the response body (e.g., in HTML). Making it a separate header not only avoids collisions (largely theoretical at this stage), it also doesn't put too much information into WWW-Authenticate (which has never had the cleanest syntax), avoiding potential parsing issues, etc. > If you answered yes to #1: > > 2. Should the WG apply this to all new HTTP authentication schemes > (currently, MAC, but potentially more)? What does "apply" mean here? Do you just want to allow people to use the same error codes with other auth schemes if they want to, knowing that most existing software won't use it? > 3. Should this new error attribute and registry be part of the main OAuth 2.0 > specification, part of one of the upcoming schemes (for use with other > schemes), or standalone? If you really want people to use it for other schemes, it needs to be a separate spec; no matter how much you say otherwise, folks assume that if it's part of a bigger spec, it's inseparable. > If you answered no to #1: > > 4. Should the Bearer draft retain the attribute and registry for its own > scheme-specific needs? Not sure how that's relevant here... Cheers, -- Mark Nottingham http://www.mnot.net/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] oauth2 implicit flow user experience
On Wed, May 11, 2011 at 3:26 PM, Lodderstedt, Torsten < t.lodderst...@telekom.de> wrote: > > > > Through registration and redirect URI validation. A native app does > > not have to impersonate, they can just register a user-agent client. > > Everything boils down to the user trusting the app. As Breno mentions, > > nothing the spec can do to help with that. > > It could recommend the authorization server not to automatically process > repeated authorizations without user consent if it cannot reliably > authenticate the client. > And, as I explained above, it would provide no additional meaningful security while at the same time eliminating the value of the user-agent profile. > > > > > Marius > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Breno de Medeiros ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] oauth2 implicit flow user experience
> > Through registration and redirect URI validation. A native app does > not have to impersonate, they can just register a user-agent client. > Everything boils down to the user trusting the app. As Breno mentions, > nothing the spec can do to help with that. It could recommend the authorization server not to automatically process repeated authorizations without user consent if it cannot reliably authenticate the client. > > Marius ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] oauth2 implicit flow user experience
On Wed, May 11, 2011 at 11:44 AM, Lodderstedt, Torsten wrote: > 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)? Through registration and redirect URI validation. A native app does not have to impersonate, they can just register a user-agent client. Everything boils down to the user trusting the app. As Breno mentions, nothing the spec can do to help with that. Marius ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] oauth2 implicit flow user experience
On Wed, May 11, 2011 at 11:44 AM, Lodderstedt, Torsten < t.lodderst...@telekom.de> wrote: > 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. > Native apps will require access to shared OS resources to retrieve the access token if the redirect URI is a web location registered with the proper web client. If the Native app has such access, the native app can do far more interesting things to compromise the users credentials directly. No amount of protocol sophistication can address this. > > 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 > > 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 > -- Breno de Medeiros ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
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 > 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
[OAUTH-WG] Fwd: OAuth Security Consideration Text
Breno did a review of the security draft. Thanks a lot! Begin forwarded message: > From: Breno de Medeiros > Date: May 7, 2011 4:25:53 AM GMT+03:00 > To: Hannes Tschofenig > Subject: Re: OAuth Security Consideration Text > > Hi Hannes, > > I have gone through the test and I have a few edits and questions. > > In the edits below, text between -- -- are supposed the be stricken > out. Example if the original is: > > They quick brown fox ... > > and my suggested edit is: > > --They--The quick brown fox ... > > it means that I am suggesting that you replace the original with > > The quick brown fox ... > > Now edits by section: - > > IN: Section 1. Definitions > > Web Application to the OAuth protocol is--are-- stored on the > server and --is-- not accessible ... > > User Agent-based Application ... they can seamlessly make use of > --it--its capabilities ... > > IN: Section 2.2 Malicious Client Obtains Authorization > > ... > > Where the client can be --authenticate--authenticated ... > > ... > > It is --higly--highly RECOMMENDED that ... > > IN: Section 2.9 Phishing Attacks > > in which users can confirm the --authentictity--authenticity of the site. > > -/edits > > 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" > > 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. > > 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. 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'. > > 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." > > 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 storage mechanism available to the application is > based on persistent storage. I suggest you strike out this sentence, > since the previous one is sufficient. > > On Session Fixation > > This section needs to cover XSRF protection, the measures des
Re: [OAUTH-WG] oauth2 implicit flow user experience
On Wed, May 11, 2011 at 11:32 AM, Breno wrote: > > > 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. >> > > A native app that can screen scrape the browser can probably also install a > keylogger. It would be very difficult or impossible to protect against a > malicious native app with access to shared OS resources. > By which I mean we should consider protection against apps with such capabilities a non-goal for this protocol and not an impediment to enabling of auto-approval modes. > > >> 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 >> > 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 >> > > > > -- > Breno de Medeiros > > -- Breno de Medeiros ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
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. > A native app that can screen scrape the browser can probably also install a keylogger. It would be very difficult or impossible to protect against a malicious native app with access to shared OS resources. > 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 > > 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 > -- Breno de Medeiros ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] oauth2 implicit flow user experience
On Tue, May 10, 2011 at 4:43 PM, Lodderstedt, Torsten 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
[OAUTH-WG] I-D Action:draft-ietf-oauth-v2-http-mac-00.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Authentication Protocol Working Group of the IETF. Title : HTTP Authentication: MAC Access Authentication Author(s) : E. Hammer-Lahav, et al. Filename: draft-ietf-oauth-v2-http-mac-00.txt Pages : 26 Date: 2011-05-11 This document specifies the HTTP MAC access authentication scheme, an HTTP authentication method using a message authentication code (MAC) algorithm to provide cryptographic verification of portions of HTTP requests. The document also defines an OAuth 2.0 binding for use as an access-token type, as well as an extension attribute to the HTTP Set-Cookie response header field. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-http-mac-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth Interim Meeting
Thanks guys. Added my name to the list. -Doug Tangren http://lessis.me ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth Interim Meeting
Doug says... > 2. Is this open to implementors of the spec in addition to it's authors? > (I'm currently implementing draft 15 as developer @ meetup.com) Eran says... > This is an official interim working group meeting which goes by all the > normal IETF rules of such meetings and is open for all. Indeed, thanks, Eran, for the reminder here. Yes, this is an open meeting -- there are NO restrictions on who may attend, other than that we ask people to sign up in advance so the logistics can be properly set up. We hope to have a room full of people who want to spend the day finishing up the OAuth specs by getting the issues resolved -- negotiating and coming up with compromises where necessary. And the meeting is also covered by the IETF's "Note Well" (as is this mailing list). Anyone who needs a reminder of what that says can look here: http://www.ietf.org/about/note-well.html Barry, as chair ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] BCP for returning HTTP Authentication (2617) Error Status (questions from the OAuth WG)
On 09.05.2011 18:49, Eran Hammer-Lahav wrote: ... The OAuth WG is seeking guidance on the following questions: 1. Should the WG define a general purpose method for returning errors with a 401 WWW-Authenticate headers, including a cross-scheme error code registry? ... Not sure. Are there error conditions servers *want* to reveal, and which also have interoperable implications for clients across authentication schemes? That is, can they really be re-used? If that's the case, a standalone document defining these parameters, with an easy way for new schemes to include these params would make sense. ... [2] http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-04 ... That being said, here are a few comments about the aforementioned spec. error = "error" "=" quoted-string error-desc = "error_description" "=" quoted-string error-uri = "error_uri" = <"> URI-reference <"> This probably should be error = "error" "=" quoted-string error-desc = "error_description" "=" quoted-string error-uri = "error_uri" "=" DQUOT URI-reference DQUOT (missing quotes around the "=", and also please avoid prose productions). Also, you do seem to ignore I18N issues with the error_description. What's the encoding? (and, as a matter of taste, I'd prefer hyphens instead of underscores in parameter names...). Best regards, Julian ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
