Enhancement: integration with external OAuth2 provider.

[cofin]

Summary

It would be great to have an integration with a third party library or have built in support for authenticating with OAuth2 providers such as Google or Github.

Basic Example

No response

Drawbacks and Impact

No response

Unresolved questions

No response

---

Funding

• If you would like to see an issue prioritized, make a pledge towards it!
• We receive the pledge once the issue is completed & verified

[JacobCoffee]

This could/would be accomplished by developing an internal plugin via https://docs.litestar.dev/latest/usage/plugins.html#plugins.

Some examples of others:

• https://github.com/litestar-org/litestar/pull/3145#issuecomment-1966921258
• https://github.com/cofin/litestar-granian
• https://github.com/guacs/litestar-svcs

[guacs]

I think we could develop a plugin for this, but imo it should be maintained as a seperate library (officially maintained by Litestar). Most likely we want to use something like authlib to implement this and if this is kept separate, then users would only have to install it if they need it.

[codespearhead]

By "external OAuth2 provider", do you mean a Python library or a separate OAuth2 provider? Because Keycloak is a no-brainer despite being written in Java.

There's also python-social-auth, which is used by Zulip and Sentry.

However, it's worth noting that both projects seem to have integrated that library's source code into their own repository. Hence, their "forks" are maintained independently, which impacts the library's health and integrity.

[JacobCoffee]

I think at this stage, we have "native" support in the library and all we need to do OAuth2 connections as a client to any server.

I'm not sure what we want here, but maybe some nice abstraction with some built-in common providers as a plugin that users can opt-in to?

@litestar-org/maintainers ?

[codespearhead]

Makes sense, because keeping the OAuth client and the OAuth provider in the same package is risky imo, given how much of a burden maintaining the latter actually is.

For reference: Laravel Socialite is an OAuth client with a few official adapters, whereas other adapters are maintained by the community.

[fkromer]

In the Django world there is the kind of de-facto standard https://github.com/pennersr/django-allauth. Could be interesting to have a look at it’s implementation. Enabling authentication using „regular accounts“ (user name + email + password or one time code) in addition to „social accounts“ (GitHub, …) would be great. This would require to provide email service provider integration https://github.com/litestar-org/litestar/issues/3520 to enable email transmission based workflows for „regular accounts“ (email verification email, password change email, …).