create-rust-app
create-rust-app copied to clipboard
Wulf
OAuth support
What's the feasibility for adding the option to use Google/Github/etc. OAuth for user authorization in addition to / instead of the current authorization method?
It would be cool to add OAuth capabilities!
We can either do it as a separate plugin (adds a table with user_id, provider, provider_user_id) or extend the auth plugin further (maybe feature gate it with flags?).
Eventually I want to separate each plugin into its own crate so we can introduce the idea of community plugins that allow all this extension and only keeping certain things as 'core' plugins.
hey @AnthonyMichaelTDM, hope all is well on your end.
Just wanted to bring #330 to your attention in case you have time to look at it. I'm going to merge it in later during the weekend after I'm sure that it doesn't break other project configurations.
As far as the implementation is concerned, there are two things I'm worried about but set aside for later:
-
Not every OIDC provider in the wild provides 'email' or 'email_verified'. For those that don't, we don't create any account; i.e. authentication/authorization fails and no external account is linked to an internal user. We need to modify the flow to allow the user to verify and or set an email individually later on but still use a non-standard OIDC flow. This is a major issue for those who want to use Microsoft as an OIDC provider as they don't return emails.
-
The table that facilitates oauth2 logins will have a lot of rows that become redundant for unsuccessful logins. Some refactoring and shifting of logic (after considering security implications) can help us prevent these redundant rows. For now though, I'm shipping with this.
What do you think is a good approach to addressing those concerns?
Would an enum for each major provider (or type of provider) work?
What do you think is a good approach to addressing those concerns?
My thoughts are that this is a great first step and the two worries I have can easily be dealt with later, when they resurface.
Would an enum for each major provider (or type of provider) work?
Yeah, at the same time, I'd prefer to document links to official sources and have end-users access those sources. We can also also provide templates for third party OIDC providers like keycloak.
Now that the base is complete, we can continue iterating and improving it :)