4 ms·
This was interesting up until I found this line in the documentation. Which is having authentication based on cookies is a non-starter for many organizations a
by koblas 6y ago
This was interesting up until I found this line in the documentation. Which is having authentication based on cookies is a non-starter for many organizations at this point.
> Authelia relies on session cookies to authenticate users. When the user visits a website of the protected domain example.com for the first time, Authelia detects that there is no cookie for that user. Consequently, Authelia redirects the user to the login portal through which the user should authenticate to get a cookie which is valid for *.example.com,
- mooreds 6y agoSetting cookies like that is a pretty standard SSO technique for the web as far as I know. Is there a superior alternative I can read up on?
- donatzsky 6y ago1. Do authentication on auth.example.com 2. Set a session cookie for auth.example.com 3. Redirect to app.example.com/?token=12345 4. Exchange token for a session cookie on app.example.com This way each (sub)domain will have it's own unique cookie.
- mooreds 6y agoAh, so the issue is that the cookie was set for the entire domain, not that a cookie was set at all. My misunderstanding. Yes, what you lay out makes sense.
- donatzsky 6y agoReading his other comment, koblas was actually talking about bearer tokens. Not sure how they are actually better than cookies, though. Certainly can be a lot more complex. With cookies you mostly just have to avoid the *.example.com foot gun.
- mcovalt 6y agoWhy is cookie based auth a problem?
- cdjk 6y agoThe *.example.com cookie is the problem. A malicious subdomain under example.com will get that cookie and can use it to impersonate users.
- XCSme 6y agoHow else do you suggest to store persistent login data?
- koblas 6y agoAuthentication: Bearer headers This avoids most cross site scripting attacks
- donatzsky 6y agoAre we talking jwt-style bearer tokens? They have their own issues. Better to have the auth server issue a single-use token that gets exchanged for a properly scoped session cookie on the app (sub)domain. Edit: Of course, then you also need some sort on central session storage, to properly deal with logging out.
- XCSme 6y agoBut where do you store those? Those have to be sent with each request.
- 411111111111111 6y agoThese are usually really short lifecycle, so they're usually just saved in a variable or session storage. A refresh often just gets a new one, as they're usually valid for 5 mins or even less.