Logging out from authentik should invalidate sessions of proxied applications #2023
Comments
|
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. |
|
I agree that this should at least be configurable, if not default. There are two reasons why it isnt currently possible:
This isn't the case because relatively few applications and libraries support it, so I haven't gotten around to implementing it
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) |
BeryJu
added
the
enhancement/confirmed
|
I see some confusion about SLO (Single Log Out)
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. |
|
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. |
|
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? |
|
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
<#2023 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFTK4Q6CHXIUKNZUWLIU4OTWP6EE3ANCNFSM5K242TZA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
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. |
|
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. |
|
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: <!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 :') |
|
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 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? |
This is basically the big problem why I cannot use Authentic for any significant professional usecase. |
|
^^ jumping in circles ^^ |
|
@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. |
|
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. |
|
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. |
|
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:
Yet when modifying the user login stage, there is no option for updating this setting. How can I configure this? |
|
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). |
|
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? |
|
Still not working in 2023.5.0 |
|
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. 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 |
|
A SSO system which does not log you out globally, having a high-priority bug open for two years without anyone clearly stating when the fix will land? Sure, I'll use it... |
|
I wish there was a solution for this. All i can do during testing is use incognito windows. |
|
JWT is the fundamentally wrong approach to user auth it seems: https://evertpot.com/jwt-is-a-bad-default/ |
|
We want to implement authentik in our Enterprie-Environment, but without global, centralized logouts, this simply isnt possible. |
|
Most of the comments in this thread are not helpful, especially since competing solutions like keycloak + oauth2_proxy behave the same way. Regardless, the PR linked above (#7099) will improve this behaviour with the next release. Aside from that we want to do some changes to the OAuth2 client in the outpost to further improve this, but there are also some challenges there that need solving (for example supporting multiple outpost instances while being able to lock sessions to prevent OAuth tokens from refreshing multiple times, for which oauth2_proxy uses redis, but I'd like to avoid adding as a dependency to the outpost) |
|
We temporarily resolved the issue with a logout button that manually triggers the "outpost-logout" call. Centralized user logouts are still a highly desired feature, but we already have a test deployment of our web app that enforces user redirection centrally. To the Authentik team, I wanted to express my gratitude for your open ears, assistance, and code work. Your support has been invaluable, and I truly appreciate your efforts. Thank you for your help! Warm regards, |
|
I can confirm that the outpost logout url work as expected however it would be nice if said url would have been visible somewhere in the Authentik Admin UI. |
|
Where is this new button / URL? I think I didn't find it because the normal logout button still only logs out from the Authentik UI and not proxied services, at least in my testing but maybe I did something wrong |
|
I am looking for a unified way to log out of sessions based on the oidc approach. When I initiate logout on the front end, I still need to choose whether to log out of the authentik account in authentik. |
|
Version 2023.10 added this feature to auto terminate all sessions when logging out via user interface logout button, but since 2023.10.3 it´s not working anymore. However, outpost logout URL does. Or am I just missing something? |
|
"Most of the comments in this thread are not helpful, especially since competing solutions like keycloak + oauth2_proxy behave the same way." Looks like their communication and solution is not helpful, either. |
Keycloak terminates the session when you use the ODIC logout url, even from all Apps. So I am not sure if you are referring to a technical detail or you mean logging out from all apps (or individual Apps) in general.
Is this fixed, is it not? 🤔 |
|
Opened a discussion on this #9737 |
|
Up until finding this post, I thought I had misconfigured something, but seems like I didn't. I also would like to solve this problem, especially with NextCloud where if user1 logs in, then goes to NextCloud, calls it a day and closes the NextCloud tab but logs out of Authentik, then user2 logs in on Authentik and also clicks on NextCloud, he apparently gets logged into user1's NextCloud account. Has anyone found a fix for this yet? |
That... Sounds like a significant bug in nextcloud.. That has nothing to do with this.. |
It stems from the same issue that if you do not explicitly click the "Logout" button in NextCloud to return to Authentik, then Authentik does not log out of the account via Backchannel or even just by sending the SLO when clicking the Logout button in Authentik. EDIT: I have tried this with Kimai, which uses SAML instead of OpenID/OIDC/OAuth2, and as soon as I click the Kimai link in the Dashboard, it goes through the Authorization flow again, thereby ensuring the correct account gets logged in. With NextCloud using OIDC however, it does not go through the Authorization flow again unless the account was previously explicitly logged out. As such, it should be possible to fix this by calling the Logout URL manually before the Authorization flow, thereby invalidating previous logins. No? |
How is Nextcloud supposed to know that you logged out of Authentik without being told to do so (which is basically this feature request)? |
Exactly, thank you. A workaround I considered was running a dedicated invalidation flow running right before the upcoming authorization flow, but I am too much of a noob with Authentik yet to set that up properly. If anyone could advise, I'd much appreciate it 🙏 PS: If you read my update to the answer above, you'll see that it does work with SAML. The problem is that NextCloud's SAML app is an absolute catastrophe and I will never touch it again because it breaks all the time, OIDC works almost perfect except for the problem that I am facing with the logout of the old session. |
Unless they are talking about a shared device for some reason, logging in to another users account on nextcloud has nothing to do with authentik. |
Absolutely correct, it's a shared device. In my test cases where I use my personal account, and then a test account, this does occur. If I only were to ever use my own account on my own device it wouldn't be a problem, but this is for a shared device as you astutely observed. As far as I'm concerned, the entire usecase for this feature would mostly be for that exact reason, but keep in mind that this occurs with any OIDC/OAuth2 app, not just NextCloud, and so since some other companies also use OIDC/OAuth2 for shared devices, this has to be taken care of somehow. Once again, the best way I can imagine to workaround this right now is by making a flow which invalidates currently logged in sessions, the problem is that I have no idea how I would go about doing that. |
|
I don't think you can solve this with a flow in authentik because the authentik session is actually already invalidated correctly. The issue is that authentik does not notify the oidc relying party so the for example nextcloud session is not invalidated as well. For a shared device perhaps it would be simplest to just configure the device to wipe session data upon closing the browser until authentik supports back channel logout. |
Not feasible sadly, as the Browser is used for more than just that. Also, people don't habitually close the Browser when done, they usually leave it open for the next person (it's an open terminal to be used). |
|
@LokeYourC3PH the problem you have encountered is exactly the same issue with outline wiki. It has nothing to do with these Apps. Sure the Apps call also a logout route but then the Authentication provider takes over. Authentik has this middleware site where you can re-login in the user1 account (as in your example) despite you are user2 because Authentik seemingly does not handle the logout properly. As Authentik (see discussion) has two logout systems in place. One for the "logout from all" and one "logout from app". Which is really weird. Logout from all does the trick for you, so you don't get the "re-login" site. It's a bit counter-intuitive. The disadvantage is that you literally log out from all apps, and this means you can't just hop over to your other app via SSO. |
|
This behaviour should be fixed! I also expect a global logout when using such a system. |
|
I'm curious to know why Single Logout works fine for me when using Incognito but doesn't work when using a normal browser session. |
and others
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_outon 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!
The text was updated successfully, but these errors were encountered: