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