Am 13.12.2010 22:27, schrieb Marius Scurtescu:
On Mon, Dec 13, 2010 at 11:00 AM, Torsten Lodderstedt
<tors...@lodderstedt.net> wrote:
section 5.2
“The authorization server SHOULD NOT issue a refresh token when the access
grant type is an assertion or a set of client credentials.”
How shall the server determine whether to issue refresh tokens in case of
grant type “Resource Owner Password Credentials”? In contrast to
authorization code, the user is not directly involved in the interaction
with the authorization server.
Not directly, but the user did provide the credentials. In this case
the only long term credentials the client has are the end user
credentials, the server better issue a refresh token so the client is
not forced to store the user credentials, right?
Agreed, it's better to store a refresh token than username/password. But
that's not my point.
The user gave the client his credentials, which is a user consent
somehow. But the user does not necessarily want to stay logged in (i.e.
he didn't disabled the respective checkbox). That's why I think we need
a way to signal this distinction to the authorization server. So the
server does not need to create a refresh token, which is useless. If you
have a more generic proposal, that's fine with me.
regards,
Torsten.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
