On 4/8/10 4:25 PM, "Marius Scurtescu" <[email protected]> wrote:
> On Thu, Apr 8, 2010 at 3:36 PM, Eran Hammer-Lahav <[email protected]> wrote:
>> This seems reasonable, but it does add more complexity for the client.
>
> True, but not that much. Just an extra request parameter if it wants a
> refresh token. Default could be "no".
Its a growing list... :-)
If the client can ask for a refresh token, why not also let it ask for a
secret in each flow, and a username, and specific UI, etc. At some point we
cross a line and the protocol becomes complex (even if rich). I'm asking
where that line is, and if this qualifies as worth of extra complexity. I
don't have an answer.
>
>> The
>> thing is, there is no point in a refresh token if the token lifetime is the
>> same as the access grant. Should the server ignore the client¹s request in
>> such cases?
>
> Lost you. What do you mean by access grant? The refresh token is
> probably unlimited, at least long lived. The client cannot control the
> lifetime of the access token either.
User approves access to his resources for 2 weeks (the access grant). The
server issues an access token good for 2 weeks. The client asked for a
refresh token (not knowing it is pointless). What should the server do?
EHL
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
