Re: [OAUTH-WG] Remark on OAuth Device Flow Draft 12

[William Denniss <[e-mail]>]

Hi Dries,

Good question. The intent of the expired_token error message is to
communicate to the device client that it should stop polling as the session
has expired. The reason we defined the separate error message for just this
case was so that clients could present an accurate message (i.e. that the
polling should conclude due to the session expiring, but the user could try
again).

There is no requirement in the specification that this error be returned on
all expired tokens, for example implementors could make the decision only
to return expired_token for 5 minutes which would enable the above UI
behavior, or to never return that code if they wanted.  There is also no
requirement to persist expired tokens, this logic is completely up to the
server.

I do think it's good behavior to persist the expired token for several
minutes after expiry and to return the "expired_token" error code during
that time, in order to help the client better serve the user, but after
that time there isn't any value in returning that error code, and no need
to persist the tokens just for that reason.

Best,
William



On Wed, Sep 5, 2018 at 11:45 PM, Eestermans Dries <[e-mail]>
wrote:

> Dear all,
>
>
>
> I’ve been implementing the device flow on my own client, and configuring
> the server side as well.
>
>
>
> I have only one remark/question regarding https://tools.ietf.org/html/
> draft-ietf-oauth-device-flow-12#section-3.5
> <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-oauth-device-flow-12%23section-3.5&data=02%7C01%7Cdries.eestermans%40is4u.be%7C74679240d3964c3cb52008d613becd1f%7C49c3d703357947bfa8887c913fbdced9%7C0%7C0%7C636718107551704981&sdata=qyCoR%2BuFUd7%2FWVUXAxpCkP3W%2Fl1Jw2eq%2FkINYaC5B5g%3D&reserved=0>
> :
>
> There’s several error codes defined, the one I’m questioning specifically
> is: *expired_token*. When you return expired_token, don’t you
> (implicitly) expose data about once-existing tokens? Wouldn’t a better
> error definition be something like; invalid_token? That way the client
> knows the code it’s using is invalid, without exposing any history of
> actual expired tokens, and can conclude the session as intended.
>
>
>
> Furthermore, if expired tokens are a thing, should the server persist
> expired tokens? If so, how long would they have to remain there? Wouldn’t
> it be easier at this point to simply discard the tokens once it expires?
>
>
>
> Kind regards,
>
>
>
> Dries Eestermans
>
>
>