-
-
Notifications
You must be signed in to change notification settings - Fork 2.4k
Description
Is there an existing feature request for this?
- I have searched the existing issues before opening this feature request.
Describe the feature you would like to see.
TL;DR
Add OAUTH as a complete, but optional replacement for the current Auth, and don't add providers let users add one via env.
Start
I saw that a few years ago, there was an attempt in adding oauth. eg #3774
This is in general a good idea, but to be honest, I don't see why anyone would want any of these solutions. Not that oauth is bad, but I think that having google/gh and more as login for such a project is absolutely stupid. Like to actually use it with google you need to create an app that has to be approved and such... to much work I would say....
That being said, oauth would be great for only one thing: integrating an existing authentication environment. (this could then have google/apple auth since centralized)
So what do I suggest?
Simple, give the ability to add only one custom oath provider, and add the option to make it the default and only (if enabled) auth method.
Probably also a feature only a minority of users could/would use (??Enterprise Version??) since it would require to bring an oauth provider (either a self made/hosed one or a saas eg. okra).
Why would you implement this?
Compared to earlier PRs, maintenance would be lower. The reason you only need to add:
- some config to disable the current login/register frontend and redirect to the custom login url.
- use eg socialite for redirecting the user and for the backend oauth thing.
- add user creation/update after oauth login
And yes we could have discussions about different implemented things, like the current sso links etc. Yes they are ok, and could be seen as the same, but here I would disagree, since environments that currently only allow login via sso links through eg a billing panel, could then allow their users to directly go to the panel without first clicking the sso link.
I am fully aware that users could just have multiple accounts... one on the billing one on that panel one here ... but let's just say, ... some might call this botching.....
Describe the solution you'd like.
Add something like this to routes or logic respectively to controllers :
Route::get('/login', function () {
return Socialite::driver('custom')->redirect();
});
Route::get('/auth/callback', function () {
$user = Socialite::driver('custom')->user();The Socialite driver custom must be created so that we can configure it via .env
and yes there are other ways to integrate this but that's the first thing I thought of...
Additional context to this request.
No response