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
