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 <dries.eesterm...@is4u.be> 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 > > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
