4 ms·

In a lot of cases, short session expiry is used as a hack around subpar authentication standards such as SAML/OIDC where there is no reliable backchannel for th

In a lot of cases, short session expiry is used as a hack around subpar authentication standards such as SAML/OIDC where there is no reliable backchannel for the identity provider to tell the service to expire sessions (following a credential change, user being deleted, etc). The short session expiry is used as a workaround to force the third-party service to regularly check-in with the identity provider, thus placing an upper bound on how long IdP-initiated changes take to reflect on all third-party services.

pcai 3y ago
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
- jmull 3y ago
  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 3y ago
    "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 3y ago
      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 3y ago
        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 3y ago
      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 3y ago
    > 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 3y ago
      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
- Perseids 3y ago
  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.
grinich 3y ago
There’s a solution for this! It’s called SCIM and it lets you sync user updates from the directory so you can expire sessions when users are deactivated. (I work at WorkOS.com which helps developers with this.)
- forty 3y ago
  I'd rather rely on session expiration rather than on the fact the SCIM sync works well. I implemented SAML and SCIM services. With SAML you implement things once, tweak it a bit, and then it works with all the IdP, even those you never heard of. SCIM on the other hand have only 2 client implementation that I'm aware of (at the time I worked with it at least) and they were sufficiently different from each other than you kind of had to do 2 implementations. Not to mention it uses stupid JSON patch thing that are crap to work with unless you use mongodb or similar I guess. And stupid limitations on forcing the sync on AzureAD that I forgot the details of.
deleted 3y ago
[deleted]
tommiegannert 3y ago
> /OIDC where there is no reliable backchannel for the identity provider to tell the service to expire sessions That's what the OAuth/OIDC refresh token is for: https://oauth.net/2/refresh-tokens/ https://oauth.net/2/refresh-tokens/
chongli 3y ago
How would those other technologies deal with the situation where grandma signs into her banking account via app on her phone and then gets distracted, leaving her phone unlocked on the table for teenage Jimmy to find? My bank uses short sessions so I get signed out within a few minutes of inactivity. Long sessions would seem to leave grandma wide open to this sort of local attack.
- graftak 3y ago
  By asking for credentials/auth for every meaningful interaction.
unscaled 3y ago
The main problem is the way these standards are implemented. OAuth 2.0 (on which OIDC is based) does define a reliable back channel for session revocation, although it is still pull-based instead of push-based. The scheme is simple: 1. Use short-lived access tokens (forcing clients to refresh often) 2. Check for revocation on every token refresh There is even an OAuth 2.0 RFC for a token revocation API[1], and an Open ID Connect extension for backchannel logout[2]. Unfortunately, many OAuth 2 implementations (especially these were refresh tokens are JWT-based) do not support revocation of refresh tokens at all. The other big problem is that refresh tokens are too often misunderstood. I've consulted quite a lot of development teams who implemented OAuth 2.0 (both as a client and an AS/RS), and most of the developers did not initially understand what the refresh token is meant to do. This resulted in a lot of wrong implementations. If I blame the standards for something, I'd blame them for being too complex and flexible. This goes without saying for SAML - nobody should be using that if they have any choice. But even simple OAuth 2.0 needs care. There are many RFCs out there, and if you just read the original RFC or one of the many low-quality guides on the interwebs, you probably would miss the point about how to properly use a refresh token. RFC 6749 subtly hints at this strategy I mentioned above, but never fleshes it out as a recommendation, let alone mandates it. OpenID Connect is even worse. It introduces a new type of token (ID Token) that has unclear purpose and security, encourages JWT use without setting up a standard for revocation, reinforces the insecure implicit flow and introduces a whole new similarly-insecure flow that serves no purpose (the hybrid flow) which serves no purpose except for making sure there are more vulnerable apps out there. Both OAuth 2.0 and OIDC can be implemented securely, but the base standards are not guiding you on how to do this, and - in the case of OIDC - contain way too many footguns. I think the OAuth 2.1[3] is a step in the right direction. GNAP[4] (a.k.a. "OAuth 3.0", "XYZ", "TxAuth") looks to me like a step in the wrong direction (even more complexity), but perhaps it's too early to tell. [1] https://oauth.net/2/token-revocation/ https://oauth.net/2/token-revocation/ [2] https://openid.net/specs/openid-connect-backchannel-1_0.html https://openid.net/specs/openid-connect-backchannel-1_0.html [3] https://oauth.net/2.1/ https://oauth.net/2.1/ [4] https://oauth.net/gnap/ https://oauth.net/gnap/
- dwaite 3y ago
  > The main problem is the way these standards are implemented. OAuth 2.0 (on which OIDC is based) does define a reliable back channel for session revocation… The larger issue is that even if you had a reliable revocation system - most relying parties wouldn't use it. The typical relying party supports logins from Facebook, Google, Apple and the like because the user chose to use those as authentication systems. However, the relying party is independent. The user would not expect other sites and desktop apps to suddenly stop working because the user hadn't visited Facebook for a certain number of hours. There were efforts in the past using transparent pixels on the identity domain to do distributed session tracking - e.g. if I'm interacting with _any site_ using the login, that will encourage the session to stay alive. Turns out that was way too much visibility for social login providers to have.
dwaite 3y ago
> In a lot of cases, short session expiry is used as a hack around subpar authentication standards such as SAML/OIDC where there is no reliable backchannel for the identity provider to tell the service to expire sessions Both SAML 2 and OIDC have standard mechanisms to expire sessions. One problem is that sessions are always a per-site, bespoke technology. Flagging a session as expired in a back-end database isn't going to help if the front-end uses cookies holding JWTs as an optimization. So some sites prefer front-end expiry (which is also standardized by both). Some sites won't bother to support either. Add on the inconsistent behavior of cookies across browsers these days, and it becomes very hard to support. It has been prioritized out of most things. There is also the issue that sign-out doesn't make sense for many things. Logging out of Google in my browser shouldn't kill my Discord desktop session just because I chose the SSO option for authentication. SLO makes sense in enterprise scenarios (where many big SaaS products tend to still not support it) and in single-party consumer scenarios - where SSO is used as integration glue to make something that "looks" like it is all one site, such as first-party Google logins.

pcai 3y ago

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

jmull 3y ago
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 3y ago
  "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 3y ago
    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 3y ago
      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 3y ago
    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 3y ago
  > 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 3y ago
    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
Perseids 3y ago
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.

grinich 3y ago

There’s a solution for this! It’s called SCIM and it lets you sync user updates from the directory so you can expire sessions when users are deactivated. (I work at WorkOS.com which helps developers with this.)

forty 3y ago
I'd rather rely on session expiration rather than on the fact the SCIM sync works well. I implemented SAML and SCIM services. With SAML you implement things once, tweak it a bit, and then it works with all the IdP, even those you never heard of. SCIM on the other hand have only 2 client implementation that I'm aware of (at the time I worked with it at least) and they were sufficiently different from each other than you kind of had to do 2 implementations. Not to mention it uses stupid JSON patch thing that are crap to work with unless you use mongodb or similar I guess. And stupid limitations on forcing the sync on AzureAD that I forgot the details of.

deleted 3y ago

[deleted]

tommiegannert 3y ago

> /OIDC where there is no reliable backchannel for the identity provider to tell the service to expire sessions That's what the OAuth/OIDC refresh token is for: https://oauth.net/2/refresh-tokens/ https://oauth.net/2/refresh-tokens/

chongli 3y ago

How would those other technologies deal with the situation where grandma signs into her banking account via app on her phone and then gets distracted, leaving her phone unlocked on the table for teenage Jimmy to find? My bank uses short sessions so I get signed out within a few minutes of inactivity. Long sessions would seem to leave grandma wide open to this sort of local attack.

graftak 3y ago
By asking for credentials/auth for every meaningful interaction.

unscaled 3y ago

The main problem is the way these standards are implemented. OAuth 2.0 (on which OIDC is based) does define a reliable back channel for session revocation, although it is still pull-based instead of push-based. The scheme is simple: 1. Use short-lived access tokens (forcing clients to refresh often) 2. Check for revocation on every token refresh There is even an OAuth 2.0 RFC for a token revocation API[1], and an Open ID Connect extension for backchannel logout[2]. Unfortunately, many OAuth 2 implementations (especially these were refresh tokens are JWT-based) do not support revocation of refresh tokens at all. The other big problem is that refresh tokens are too often misunderstood. I've consulted quite a lot of development teams who implemented OAuth 2.0 (both as a client and an AS/RS), and most of the developers did not initially understand what the refresh token is meant to do. This resulted in a lot of wrong implementations. If I blame the standards for something, I'd blame them for being too complex and flexible. This goes without saying for SAML - nobody should be using that if they have any choice. But even simple OAuth 2.0 needs care. There are many RFCs out there, and if you just read the original RFC or one of the many low-quality guides on the interwebs, you probably would miss the point about how to properly use a refresh token. RFC 6749 subtly hints at this strategy I mentioned above, but never fleshes it out as a recommendation, let alone mandates it. OpenID Connect is even worse. It introduces a new type of token (ID Token) that has unclear purpose and security, encourages JWT use without setting up a standard for revocation, reinforces the insecure implicit flow and introduces a whole new similarly-insecure flow that serves no purpose (the hybrid flow) which serves no purpose except for making sure there are more vulnerable apps out there. Both OAuth 2.0 and OIDC can be implemented securely, but the base standards are not guiding you on how to do this, and - in the case of OIDC - contain way too many footguns. I think the OAuth 2.1[3] is a step in the right direction. GNAP[4] (a.k.a. "OAuth 3.0", "XYZ", "TxAuth") looks to me like a step in the wrong direction (even more complexity), but perhaps it's too early to tell. [1] https://oauth.net/2/token-revocation/ https://oauth.net/2/token-revocation/ [2] https://openid.net/specs/openid-connect-backchannel-1_0.html https://openid.net/specs/openid-connect-backchannel-1_0.html [3] https://oauth.net/2.1/ https://oauth.net/2.1/ [4] https://oauth.net/gnap/ https://oauth.net/gnap/

dwaite 3y ago
> The main problem is the way these standards are implemented. OAuth 2.0 (on which OIDC is based) does define a reliable back channel for session revocation… The larger issue is that even if you had a reliable revocation system - most relying parties wouldn't use it. The typical relying party supports logins from Facebook, Google, Apple and the like because the user chose to use those as authentication systems. However, the relying party is independent. The user would not expect other sites and desktop apps to suddenly stop working because the user hadn't visited Facebook for a certain number of hours. There were efforts in the past using transparent pixels on the identity domain to do distributed session tracking - e.g. if I'm interacting with _any site_ using the login, that will encourage the session to stay alive. Turns out that was way too much visibility for social login providers to have.

dwaite 3y ago

> In a lot of cases, short session expiry is used as a hack around subpar authentication standards such as SAML/OIDC where there is no reliable backchannel for the identity provider to tell the service to expire sessions Both SAML 2 and OIDC have standard mechanisms to expire sessions. One problem is that sessions are always a per-site, bespoke technology. Flagging a session as expired in a back-end database isn't going to help if the front-end uses cookies holding JWTs as an optimization. So some sites prefer front-end expiry (which is also standardized by both). Some sites won't bother to support either. Add on the inconsistent behavior of cookies across browsers these days, and it becomes very hard to support. It has been prioritized out of most things. There is also the issue that sign-out doesn't make sense for many things. Logging out of Google in my browser shouldn't kill my Discord desktop session just because I chose the SSO option for authentication. SLO makes sense in enterprise scenarios (where many big SaaS products tend to still not support it) and in single-party consumer scenarios - where SSO is used as integration glue to make something that "looks" like it is all one site, such as first-party Google logins.