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
