[pcai]

This is correct, but its uncharitable to call it a "hack" in many contexts. In oauth, for example, the access token / refresh token concept is literally spelled out in the spec. It's not a workaround, its how you implement eventual consistency in a loosely coupled system where the IDP can't push updates to clients because it doesn't know all of them by design

[Perseids]

It's fair to argue that point. If you need something like that, then this aspect of OIDC etc. is not a hack. But really really few people take a look at the question of how to integrate an external identity provider and then decide that loosely coupled, eventually consistent is the right choice. Instead developers mostly just choose whatever seems sufficiently popular and build their system around it and only look somewhere else if the popular choice is visibly much worse at its job than the alternatives. ("visibly" with the knowledge about the topic at hand that is. Most people I've talked to just see OIDC flows as a given fact about how authentication has to work.)

From a practical perspective, there are lots of applications out there which are perfectly reachable from the outside and which use an OAuth2/OIDC library as a standard component where they could forward an update from the identity provider with a simple library call. And think about how much edge cases in front-end applications could eliminate, if you wouldn't have to be ready to get a new token at any moment, because the current one has just expired. [1]

In my opinion, pushing updates to clients should be the default of identity protocols which you only opt-out of, if you have special needs. And then hopefully documentation tells you very clearly to have very short token expirations.

[1] And yes, you technically still have to be prepared for that at any time, but you can push the trade-off of making that case less user friendly much further, if it occurs only seldom.

[jmull]

Hang on, we're talking about user sessions and you're talking about access tokens.

Short expiration of sessions is bad because of the terrible UX. Access tokens can be refreshed without user interaction, so it's not the same issue there.

[Zetice]

"Session" here is the word used for the duration in which an access token is valid. You may be talking about UX, but the submission is talking about access tokens.

[kyle-rb]

The article specifically mentions the need for users to re-enter their username and password as a downside of short-lived sessions, so I think the author's definition of "session" extends as long as the refresh token lasts.

I think that most of the non-short-session examples — Google, Microsoft, GitHub, etc — are using an access token + refresh token pattern.

[Zetice]

That's because it's a poorly written article by someone who doesn't know the difference. It interchangeably talks about issues only with the UX and the actual technical backend pieces involved.

[dwaite]

The length of time an access token is a delegated authorization, not an authentication session. For first party mobile apps and the like, they might act similarly, but for other use cases they will not.

The access token may be so my account at an event coordination site has free/busy access to my Google calendar, and that authorization might last for years.

[mschuster91]

> Access tokens can be refreshed without user interaction, so it's not the same issue there.

Not on mobile, when the app is not in foreground or gets killed by "energy saver" mechanisms - Samsung is fucking annoying in that regard, even on 4GB RAM and more it keeps closing Chrome with 10 tabs after a minute or two and it completely loses state, as do many games - even taking a call in foreground can be enough.

[NavinF]

4GB is not a lot on Android so 10 tabs sounds about right. You need a lot of wiggle room for garbage collection to be efficient and you can't swap to flash without burning write cycles and power on small devices.

That aside, I don't see any technical reason why you can't renew a token that expired 1 week ago. Renewal just makes sure nothing changed (Eg user hasn't been deleted) while you were gone. It doesn't have to do any user-facing auth