Am 31.05.2011 20:00, schrieb Doug Tangren:
-Doug Tangren
http://lessis.me
On Tue, May 31, 2011 at 1:41 PM, Chuck Mortimore
<cmortim...@salesforce.com <mailto:cmortim...@salesforce.com>> wrote:
Updated in language I just sent out – thanks.
On that note, we currently return refresh_token using the implicit
grant type under certain controlled circumstances. Facebook in
turn uses the implicit grant type, and simply issues long term
access_tokens.
Are there any strong objections to adding optional support for
referesh_token on the implicit grant along with security
considerations?
I was under the impression that one should not issue a refresh_token
in an implicit grant flow because in order to make a refresh_token
request call, you'd need send client credentials including the clients
secret which an implicit client can not store securely.
It is possible to obtain refresh tokens using the authz code grant type
without client authentication. So why not do the same with implicit
grant? As long as the user authorizes the issuance of such tokens I
don't see any problem. The refresh token is a client instance secret
associated with the grant authorized by the end user and is issued to
the originator of the authz request only. The problem with native
clients is the distribution of client secrets not their aibility to
securely store a dynamically created instance-related secret.
regards,
Torsten.
I think there is still a usability issue with the implicit flow in
general where there is no way in the spec to obtain an access token
without re-asking the user for authorization a second time even if the
user has already authorized your client.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
