It‘s not as black and white here. Yes you‘d not store anything in your application, but also you‘re using effectively stateless authentication, which means no way to boot an active session proactively as a measure to prevent more damage from an already compromised session. That‘s why I generally suggest using SSO to do the initial authentication to start a session, but do the session handling internally from there.
LostKobrakai
danschultzer
Pow Core Team
Yes you‘d not store anything in your application, but also you‘re using effectively stateless authentication
Right, good callout. If you do need to manage sessions host side, want to roll sessions, keep long running session, or dealing with high risk app, then yes, you shouldn’t do this. But that does make for a much more complicated auth story in your app.
In what I described you would let the provider deal with auth state/session management, and just have short lived stateless token host side. That’s why you need the TTL in the session/JWT, and force reauthentication when TTL is reached. The flow would be transparent for the end-user if they still have an active session provider side.
This is just like how you would implement super user privilige change, with a set TTL limit, requiring users to reauth whenever the privilige has expired. The TTL MUST be sensible, best if it’s below 30 minutes.
Important to understand that stateless authentication means that the session doesn’t get destroyed when you log out. You can remove it from the cookies, but anyone who have access to it can use it until TTL has been reached. It’s not a big deal with a sensible TTL, and we can let the provider worry about the user session.
If anyones interested, OWASP has some docs on this:
https://mas.owasp.org/MASTG/General/0x04e-Testing-Authentication-and-Session-Management/#stateful-vs-stateless-authentication
https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_for_Java_Cheat_Sheet.html#consideration-about-using-jwt
3
asrocha
Hi @danschultzer
congratulations for your great packages, I newbie in elixir, using Phoenix framework 1.7
My application is multi-tenant (postgres schemas) using triplex.
I working a lot to integrate Oauth or OIDC with keycloak.
I have tried in a sigle application and it works, but in the multi-tenancy it a complex problem.
Each tenant on phoenix is a realm on keycloak so the config need to be build dinamically
I I couldn’t handle it correctly with the callback
have you any guide or advisory to fix it
0
AMBasra
Just a question. Have you used it with LiveView.
I am having a hardtime using it with Live View.
If possible can you refer to some repo if you have open sourced it ?
0
derek-zhou
No, I don’t have an example application ready to share. What problem are you facing? As far as I know, Ueberauth has nothing to do with Live View; all it does is to give you success or failure in a controller callback; it is up to you to manage the session however you want and possibly redirect to a Live View route.
0
AMBasra
Well the issue is pretty stupid.
When I redirect to google for auth I am getting redirect_uri mismatch.
I have setup my redirect_uri correctly in my config.
I am new so I might be totally wrong here but I think the route user_oauth_path works with @conn seamlessly but not with socket. I think we might need to write extra code for this.
0
sodapopcan
I am unfamiliar with uberauth but you can’t perform any actions that set session/cookie data in LiveView events. Anything that does so must use a regular controller (ie, with @conn), though you can still redirect back to a LiveView once it’s done. This is a limitation of websockets, not LiveView.
1
mmeyerlein
hi @asrocha
have you made any progress with your project?
i have an almost identical setup, but the tenants are not separated into realms, but into clients, because keycloak tends to have performance problems with a lot of realms.
i would be very interested to know what solution you came up with. have you tried ash?
0
marcin
Hello @rsmrsm @mmeyerlein @sodapopcan @AMBasra @asrocha and others.
I see this topic is a popular source of confusion and started to write a guide on Phoenix auth with phx.gen.auth and external providers.
So far I’ve written two parts, start here: Poenix auth in 2024
I think I also would want to write on token revocation issues discussed above, and perhaps about multi-tenancy (I’d love to hear how you envision it though @asrocha )
I will be happy if you give me some feedback on the guild - best via a private message. I write technical doc, but not guides usually, I am not sure if I have balanced well how basic it is. It was fun to write though and I hope you find it useful!
(the text may have typos – sorry – but I have already a fatigue from looking at it and probably am missing them. Will re-read it again after a break!)
All best,
Marcin
11