Logging out from authentik should invalidate sessions of proxied applications

[rperpe]

trafficstars

Is your feature request related to a problem? Please describe. If users logout from authentik they expect that they're logged out from proxied applications (using embedded outpost and integrated proxy provider) too - without GETting /akprox/sign_out on every single application. It's a security risk if users don't consider this.

Describe the solution you'd like As soon as https://authentik.tld/flows/-/default/invalidation/ is called, all sessions on proxied applications must be invalidated immediately (probably via OIDC back-channel logout?). Same is expected if forward auth proxy provider is used (assuming there exists the same issue).

Describe alternatives you've considered Are there any alternatives/workarounds (instructing users to manually logout from every single application isn't considered as a workaround)?

Additional context N/A

PS: Many thanks to @BeryJu for his hard work and sharing authentik on GitHub!

[xpufx]

I do agree that it's a security issue when the user logs out of one app and calls it a day not realizing all it would take to log back in is to go to the login page again. Same for other apps they haven't even considered the fate of.

However it would also confuse a lot of users when they log out of their webmail account and now their kanban software is logged out too.

The other thing is, the applications need to play along with this as well. Not all apps allow you to change what happens when you hit that log out button. Authentik needs to know when it happens for it to be able to do something, no?

This doesn't look like as straight forward as it might seem at first. If it were to be implemented somehow, I'd like the behavior to be configurable.

[BeryJu]

I agree that this should at least be configurable, if not default. There are two reasons why it isnt currently possible:

• authentik doesnt support OAuth Backchannel Logout, which is how authentik would tell an outpost that a user logged out.

This isn't the case because relatively few applications and libraries support it, so I haven't gotten around to implementing it

• The authentik Outpost can't remove sessions in the background

Because the way sessions work with gorilla/sessions, the outpost can only delete a session in the context of an HTTP request, and can only delete the session of that specific HTTP request. I briefly looked for an alternative library but didnt find anything with the required features (ability to remove sessions without HTTP request, Redis and FS Storage)

[PrivatePuffin]

I see some confusion about SLO (Single Log Out) Lets seperate a few things:

1. Proxied applications and apps using forwardAuth with multiple authentik applications defined
2. SAML/OIDC
3. LDAP

---

1. It should be possible to invalidate other authentik applications, when one of them is logged out. forwardAuth definately supports this.

2. When a logout request from a SAML/OIDC application hits, we can also logout applications using proxied/forwardAuth applications. However, indeed not all SAML/OIDC applications support backchannel logout and SLO (or rather: most do not)

3. LDAP does not support SLO afaik, as it just says "YAY or NAY" and sends some userdetails, so case closed (basically)

It should be relatively easy to do SLO for applications using proxied/forwardAuth, by allowing administrators to set "logout groups" for Apps that need to be logged-out together.

For SAML/OIDC this gets weird, some users might want to logout a proxygroup together with a SAML/OIDC logout, but some might not realise other SAML/OIDC sessions are not logged-out at the same time. But I think the option to also logout a group of proxied/forwardAuth applications cán technically be offered.

[QuarkZ26]

So, am I to understand that logging out of Authentik doesn't really do anything? when I log out and go back to the app, I'm still not prompted. It seems like a major issue to me, what if I log into some public machine? Even restarting the browser doesn't do anything.

[oomenit]

I just noticed this as well. This is quite a security concern. All my forwardAuth'ed apps are staying logged in, even though I'm explicitly logging out through Authentik.

I was under the impression that every request made to subdomain.domain.tld would check authentication against Authentik?

I'm coming from Authelia, and with the same forwardAuth-style authentication, Authelia does redirect me to the login page on all forwardAuth'ed apps as soon as I'm logged out of Authelia itself.

Or should I need to play around with the token validity?

[slimshizn]

Needs to be fixed. I lowered token validity to 1hr but still needs to be changed to immediately log out. Especially if the user is removed and still has access temporarily because of it...

On Fri, Dec 30, 2022, 8:30 PM oomenit @.***> wrote:

I just noticed this as well. This is quite a security concern. All my forwardAuth'ed apps are staying logged in, even though I'm explicitly logging out through Authentik.

I was under the impression that every request made to subdomain.domain.tld would check authentication against Authentik?

I'm coming from Authelia, and with the same forwardAuth-style authentication, Authelia does redirect me to the login page on all forwardAuth'ed apps as soon as I'm logged out of Authelia itself.

Or should I need to play around with the token validity?

— Reply to this email directly, view it on GitHub https://github.com/goauthentik/authentik/issues/2023#issuecomment-1368141851, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFTK4Q6CHXIUKNZUWLIU4OTWP6EE3ANCNFSM5K242TZA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[QuarkZ26]

I just noticed this as well. This is quite a security concern. All my forwardAuth'ed apps are staying logged in, even though I'm explicitly logging out through Authentik.

I was under the impression that every request made to subdomain.domain.tld would check authentication against Authentik?

I'm coming from Authelia, and with the same forwardAuth-style authentication, Authelia does redirect me to the login page on all forwardAuth'ed apps as soon as I'm logged out of Authelia itself.

Or should I need to play around with the token validity?

I went back to Authelia, personally. Given the last response that was given here almost a year ago. It seems crazy to me to leave something like this without any resolution. This plus other issues made me move back.

[PrivatePuffin]

I just noticed this as well. This is quite a security concern. All my forwardAuth'ed apps are staying logged in, even though I'm explicitly logging out through Authentik. I was under the impression that every request made to subdomain.domain.tld would check authentication against Authentik? I'm coming from Authelia, and with the same forwardAuth-style authentication, Authelia does redirect me to the login page on all forwardAuth'ed apps as soon as I'm logged out of Authelia itself. Or should I need to play around with the token validity?

I went back to Authelia, personally. Given the last response that was given here almost a year ago. It seems crazy to me to leave something like this without any resolution. This plus other issues made me move back.

Same here, Authelia is a slow-simply-and-steady development. But it at least does, what it does, well and trustworthy.

[mrjk]

Just here as well to bump this issue, it's pretty annoying problem and a quite big security issue from my point of view. Maybe this behavior should be manageable with a switch ?

But for now, this is really annoying.

[mrjk]

I found an ugly workaround. The idea is a simple HTML page that will delete all cookies of the domain, you just need to host that page under the domain you manage, ie: https://logout.company.com/logout.html?d=company.com. For the POC, it ask you before actually logoff, I guess this page could be fully parametrized, but just here to validate poc workaround.

<!DOCTYPE html>
<html>
<head>
  <title>AK Logout</title>
</head>
<body>

<script>

  var query = window.location.search.substring(1);
  var url = new URLSearchParams(query);
  var domain = url.get("d");
  var logout_url = "https://accounts." + domain + "/flows/-/default/invalidation/";

  // Delete all cookies
  function clean_cookies(domain) {
    var cookies = document.cookie.split(";");
    for (var i = 0; i < cookies.length; i++) {
      var cookie = cookies[i];
      var eqPos = cookie.indexOf("=");
      var name = eqPos > -1 ? cookie.substr(0, eqPos) : cookie;
      var result = name + "=;expires=Thu, 01 Jan 1970 00:00:00 UTC; path=/; domain=" + domain;
      console.log(result);
      document.cookie = result;
    }

  }

  // Confirm user
  if (confirm('You will be disconected of all "' + domain + '" applications.')) {
      clean_cookies(domain)
      window.location.href = logout_url;
  } else {
    console.log('User aborted logout.');
  }

</script>

<p><a href="javascript:window.location.href=window.location.href">Refresh this page</a></p>
</body>
</html>

As you guessed, I'm not a frontend dev :')

[github-cli]

That would "only" delete the cookies, the actual token would still be valid, meaning if someone had that, they could still access the site for as long as the token is valid :-(

I am not so sure people are even aware of this! I have been using authentik for a year now and was unaware of it until yesterday. Even manually "logging out" via https://authentik.fqdn.com/application/o/<appName>/end-session that you place on your website does not actually log you out (you get a confirmation screen but even if you also log out of authentik itself, the session stays valid). The flow to "invalidate" a session actually does not invalidate the sessions... It does give the impression that it should work and you should be logged out but as Berry mentioned, this "feature" (being able to log out, aka invalidating sessions) will not be implemented as its currently not possible to do so with the architecture of the outposts.

I am still a bit baffled as this would be a basic mandatory "feature" I would just assume to work.

Does anyone have any actual workarounds to this?

[PrivatePuffin]

as its currently not possible to do so with the architecture of the outposts.

This is basically the big problem why I cannot use Authentic for any significant professional usecase.

[github-cli]

^^ jumping in circles ^^ yeehaw! seems maybe this will be added such a relief!!

[slimshizn]

@BeryJu was the recent fix supposed to log out proxied applications? E.g Say I use authentik proxy provider in front of a website with no auth. If I add a user, the user has access to said website.

If I remove the user, delete their session, remove the explicit consent, the user then should not have access to said website. I'm still seeing the same behavior as before, where the user is still able to access the website, even after removed, or logged out.

[wrt54gl]

@BeryJu was the recent fix supposed to log out proxied applications? E.g Say I use authentik proxy provider in front of a website with no auth. If I add a user, the user has access to said website.

If I remove the user, delete their session, remove the explicit consent, the user then should not have access to said website. I'm still seeing the same behavior as before, where the user is still able to access the website, even after removed, or logged out.

I am having this problem as well.

[Liquidtouch]

Same here. If I log out of Authentik it appears that I have logged out but If I navigate to "app.domain.com" afterwards which is using Authentik for authentication I still have access to the site. This seems like it would be a massive security issue.

[hacustom]

Seeing the same behavior on my instance. Got things setup behind Nginx, loving the ease of setup and how well it works. I tested out multiple methods of invalidating the user/session/token - deleting the user, changing token longevity, logging out of Authentik but was always still authenticating.

[HipyCas]

I see that this seems fixed with PR #4605, and the only thing I could find about this in the documentation is this (in the User login stage:

Terminate other sessions

When enabled, previous sessions of the user logging in will be revoked. This has no affect on OAuth refresh tokens.

Yet when modifying the user login stage, there is no option for updating this setting. How can I configure this?

[oblivioncth]

Some clarification on the current state of affairs with this, and how in practice to ensure access to a page is revoked once a user has been logged out would be appreciated. The issue has been closed due to the aforementioned PR, but it doesn't seem like it's currently possible to directly take advantage of the changes given that the initially reported behavior appears to remain.

I've confirmed in my own setup that logging out does not invalidate access to domains behind forward auth (per-application).

[franciscomfcmaia]

Not working, currently using 2023.4.1.

I assume that #4605 should fix this? I see this is still an issue. Someone correct me if I'm wrong.

Apart from setting sessions to 1 hour does anyone else have any solutions?

[stignarnia]

Still not working in 2023.5.0

[github-cli]

Works for me ever since this PR was implemented. My setup is just the integrated outpost on docker with forward auth from nginx. If I go to authentik and manually log out, new connections will not be authenticated anymore. I have not tested a logout url specific to the application, I only tested a complete logout from authentik.

if you have a more advanced setup, maybe post some details of your setup and also the exact details/files used for forward auth as improper config could have an impact here as well. Steps to reproduce the issue

[github-cli]

I see that this seems fixed with PR #4605, and the only thing I could find about this in the documentation is this (in the User login stage:

Terminate other sessions

When enabled, previous sessions of the user logging in will be revoked. This has no affect on OAuth refresh tokens.

Yet when modifying the user login stage, there is no option for updating this setting. How can I configure this?

I believe what you are talking about is separate from this issue. This would log you out of authentik if you login someplace else… well and in that case I guess also invalidate your session cookies from the logged out PC… I haven’t tried if that combination works but I believe you are mistaking the two features here

[oblivioncth]

Works for me ever since this PR was implemented. My setup is just the integrated outpost on docker with forward auth from nginx. If I go to authentik and manually log out, new connections will not be authenticated anymore. I have not tested a logout url specific to the application, I only tested a complete logout from authentik.

if you have a more advanced setup, maybe post some details of your setup and also the exact details/files used for forward auth as improper config could have an impact here as well. Steps to reproduce the issue

Perhaps I've misunderstood, but I was under the impression that the point of this feature was to immediately invalidate all current sessions upon logging out of Authentik, hence outpost wide logout. Of course new connections would not be authenticated once your logged out, but this is in regards to existing ones.

If it ends up mattering, I'm using Traefik with individually forwarded applications.

[github-cli]

probably depends on the application? It would not be able to disconnect existing tcp sessions, so something like guacamole that keeps the tcp session open will continue to work until closed.

The only thing that can be influenced are new authentication requests (e.g. a "normal" html website whenever you click on a new link)

Before this PR, the behavior was like this:

1. you have 10 applications
2. you log in to application 1 via authentik and it works
3. you navigate to application 2 and are automatically authenticated as you are still logged in
4. you navigate to application 3 and are automatically authenticated as you are still logged in
5. you log out of authentik
6. you close all application tabs
7. you try to access application 4-10 and they require you to login
8. you try to access application 1-3 and those will still open indefinetely until you clear your cookies or the timeout of the application has been reached

In my opinion that is not how this should have worked and in the end this behavior was changed as described in the PR now after this change, step 8 would not allow you top open those applications anymore (big improvement!!!)

[stignarnia]

In my opinion that is not how this should have worked and in the end this behavior was changed as described in the PR now after this change, step 8 would not allow you top open those applications anymore (big improvement!!!)

Yeah but I tried it just now in Chrome and 2023.5.0 and didn't work.

• opened the main UI
• opened application 1
• log out from the UI
• close Chrome
• open Chrome
• navigate to application 1
• still working

I don't know if it's just my configuration that doesn't support the change for some reason, as I'm using the integrated reverse proxy

Edit: I see it was added to the next release, so clearly there is still something wrong. It's great that they want to address it, still curious about how you got it to work though!

[github-cli]

I am using swag (nginx reverse proxy with authentik configs already included) and the steps you describe work for me, I dont need to close and open chrome again even, after logging out of the authentik UI, I cannot open application 1 anymore. I run all this in a containerized environment (docker), I use the integrated outpost as I only use this for my homelab environment for stuff thats accessed mostly by only me and my wife.

But yea, I guess if Berry reopened this, there is probably a known issue...

[BeryJu]

The PR that closed this changes the behaviour that when accessing /outpost.goauthentik.io/sign_out it'll log a user out from all applications in that provider, but this issue is about that happening automatically when logging out from the main authentik server

[tograss]

I would also like too raise support and awareness for this issue. Supporting SingleLogOut is critical for most businesses, even if not all SAML/OIDC applications support this, those which do should be fully supported by authentic. I.e it works with zoom and simpsamlphp.

[masterit-dev]

Anybody found some workaround?