Hacker News Reader

Comment by koblas | Hacker News Reader

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,

View on HN

Setting 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?

1. 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.

Ah, 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.

Reading 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.

Why is cookie based auth a problem?

The *.example.com cookie is the problem. A malicious subdomain under example.com will get that cookie and can use it to impersonate users.

How else do you suggest to store persistent login data?

Authentication: Bearer headers

This avoids most cross site scripting attacks

But where do you store those? Those have to be sent with each request.

These 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.

Are 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.

Reply on news.ycombinator.com