We don’t issue expires_in for two reasons 1) we have variable length access tokens who’s lifetime can be extended through activity and we find clients misinterpret expires_in to be absolute (or have no practical means of finding out when it updates)
2) we find it actually makes things worse - with proactive knowledge of when a token expires, aggressive clients tend to keep it alive or proactively refresh the token. As a result the intent to limit the length of the access token actually causes it to be extended in practice. > On Dec 18, 2018, at 4:17 AM, Ludwig Seitz <ludwig.se...@ri.se> wrote: > >> On 18/12/2018 12:59, David Waite wrote: >> My understanding was that this parameter was advisory to the client - >> it neither mandated the client discard the token after the expires_in >> time, nor has a requirement that the token is no longer honored by >> protected resouces at that point in time (vs earlier or later). > > That is my understanding as well, I would however have expected that this > parameter would be aligned with the 'exp' claim of the token. > > /Ludwig > > > -- > Ludwig Seitz, PhD > Security Lab, RISE > Phone +46(0)70-349 92 51 > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
