Re: [OAUTH-WG] expires_in

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 - wit

Re: [OAUTH-WG] expires_in

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 earli

Re: [OAUTH-WG] expires_in

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). Is there meaning that ot

Re: [OAUTH-WG] expires_in

It does sound like a best practice and nearly all the providers I've ever worked with do have an expiration for ATs, however there are counterexamples (most notably, dropbox ) and they seem to be doing fine so far. Do we know anyone on Dr

Re: [OAUTH-WG] expires_in

This is probably a best practice, but we should be careful to not oversell the benefits. Unless you measure token lifetime in a small number of seconds, then it’s doubtful that any realistic attack will be stopped by this. It’s mostly useful at defending against opportunistic attacks - e.g. a to

[OAUTH-WG] expires_in

Hi all, In a recent email conversation on the IETF ACE mailing list Ludwig Seitz suggested that the expires_in claim in an access token should actually be mandatory. Intuitively it feels like access tokens shouldn't have an unrestricted lifetime. I am curious whether recommendations would be us

Re: [OAUTH-WG] expires_in RE: OAuth meeting notes on -05 (with updates)

I prefer to keep this as seconds. In most cases, this will be good enough and will not require any clock sync. Servers should not issue tokens with durations that are too short and likely to expire during processing. If clock sync is requires, the client can use the server's Date response header

Re: [OAUTH-WG] expires_in RE: OAuth meeting notes on -05 (with updates)

-WG] expires_in RE: OAuth meeting notes on -05 (with updates) Hey Axel, We had previously decided (I can try to dig up the link) that relative times will be easier for client developers. It means no timezone handling but being able to store the expiration as time() + expires_in. No, it's not

Re: [OAUTH-WG] expires_in RE: OAuth meeting notes on -05 (with updates)

Hey Axel, We had previously decided (I can try to dig up the link) that relative times will be easier for client developers. It means no timezone handling but being able to store the expiration as time() + expires_in. No, it's not going to be perfect to the second but the AS could always send an ex

[OAUTH-WG] expires_in RE: OAuth meeting notes on -05 (with updates)

During the meeting we had a (short) discussion about the expires_in parameter. I propose to change it to a notonorafter parameter with a GMT/UTC date as value. If the time slew between server is bigger or nearly equal to the life time of the expires_in value than the token receiver has no chance