[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

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

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

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

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

[OAUTH-WG] exp claim ... was RE: expires_in

Hi David, You just caught an error. Thanks. There is the expires_in parameter sent from the AS to the client and the exp claim in the access token created by the AS for consumption by the RS. I meant to write about the exp claim but I instead looked up the expires_in. The value in the expires_

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] exp claim ... was RE: expires_in

The "exp" claim is an implementation detail of one type of access token, but obviously doesn't have any meaning to someone using non-JWT tokens. Since not everyone is using JWT access tokens, it seems strange to have a mention of a JWT-specific detail. That said, it sounds like the proposal is to

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

I claim no particular expertise here and it's admittedly been a long time since I actually tested the behavior myself. But in my prior experience there were browsers that would prompt the user even when there were no certificates/keys configured for or available to the browser. On Mon, Dec 17,

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 for Browser-Based Apps

Hi Hannes, while I think the current text needs some substantial work, I support the adoption of this draft as a working group document. I also think we need to carefully define the boundaries between the Security BCP and the SPA BCP in order to prevent unnecessary duplications and inconsisten

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 for Browser-Based Apps

+1 Phil > On Dec 18, 2018, at 10:14 AM, Torsten Lodderstedt > wrote: > > Hi Hannes, > > while I think the current text needs some substantial work, I support the > adoption of this draft as a working group document. I also think we need to > carefully define the boundaries between the Secu

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 for Browser-Based Apps

I am in favor of adopting this as a working group document. There is a clear need for updated guidance for these clients. -- Annabelle Richard Backman AWS Identity On 12/17/18, 1:02 PM, "OAuth on behalf of Hannes Tschofenig" wrote: Hi all, We would like to get a confirmation

Re: [OAUTH-WG] exp claim ... was RE: expires_in

On 18/12/2018 17:06, Aaron Parecki wrote: The "exp" claim is an implementation detail of one type of access token, but obviously doesn't have any meaning to someone using non-JWT tokens. Since not everyone is using JWT access tokens, it seems strange to have a mention of a JWT-specific detail.