On Wed, May 11, 2011 at 11:32 AM, Breno <breno.demedei...@gmail.com> 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 <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 > > -- Breno de Medeiros
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
