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] 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 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 -- 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 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] 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 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 -- 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 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)? 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 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
[OAUTH-WG] oauth2 implicit flow user experience
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? Thanks -Doug Tangren http://lessis.me ___ 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 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
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
