I am just looking for a simple way to sign in users from GitHub and GitLab.
I am using Phoenix 1.6, so my go to auth base is phx.gen.auth.
How to add oauth to this?
I found a post from 2021, suggesting to use Ueberauth.
Trying it out: ueberauth version 0.10 and ueberauth_github 0.8 – i instantly discover that ueberauth_github requires ueberauth 0.7 (very old release) and will not work with a recent one. So something y is going on here – the same team maintains these two packages, but plugins lag behind big time.
The other battle tested options is to use POW. However, AFAIK pow replaces phx.gen.auth, so might be an overkill to use with recent phoenix.
When I check both project repositories, both have low commit frequency in last year. Are they finished and complete and this is why contributions are low?
Perhaps there is some other package that you currently use with phx.gen.auth?
If you integrate it with mix phx.gen.auth, consider writing an article or even a guide for the project if one does not yet exist (and check if Dan would accept it).
Thank you for the tip! Do I understand correctly I can use pow-auth/assent directly with phx.gen.auth (and it’s schemas) without using pow at all (indeed assent does not list pow as dep)?
I’m not sure if those are two things that should be used together - a lot of the machinery produced by phx.gen.auth is focused on hashed password maintenance, which is specifically the thing that an Oauth-based auth system doesn’t need.
It also brings a lot of machinery to properly handle user sessions, which is exactly what oauth systems usually don’t bring (or vastly overengineer). I’ve stripped pw handling out of phx.gen.auth successfully in the past and it’s great to have the option to add the removed code back in when needed.
Also the code for account confirmation can be useful depending on how things should work.
As already said, Assent doesn’t require Pow/PowAssent. It’s a low-level multi-provider framework abstracting away OIDC, OAuth 2.0, and OAuth 1.0. The only dependencies are related to JWT parsing and HTTP client (I strive to keep a minimal dependency graph). PowAssent is build on top of it, and deals with all the complexity of user registration.
I know you said you are going to support password, but for anyone else wanting to do something like this and only want provider authentication I would recommend not using phx.gen.auth or Pow at all. You can just add the user info to the signed/encrypted session cookie (with an expiration timestamp!) or use a JWT when succesfully authenticating, and store whatever provider was used as a cookie. When the session info/JWT expires just redirect to the provider again to reauth. The less surface you add, the better for security.
Finally as for Pow, it’s a complete package. I’m planning a larger rewrite of how it works to improve observability and also have built-in LiveView support. I’m currently updating Pow to support Phoenix 1.7 with all the breakling changes 1.7 introduces.
Unfortunately only got so much time to maintain my open source projects
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.
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.
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
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 ?
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.
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.
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.
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?
I’m curious to know what was your final retained solution to combine both password authentication and oauth ?
And if that solution works with liveview?
way to sign in users from GitHub and GitLab.
y is going on here – the same team maintains these two packages, but plugins lag behind big time.
