If you are looking to add another provider, one can do so here: https://github.com/cmackenzie1/torii-rs/tree/main/torii-auth...

If you want change the plugin logic completely, you can implement the Plugin trait and register the plugin with the plugin manager: https://github.com/cmackenzie1/torii-rs/blob/main/torii-core...

Doing the latter, you can also bring your own storage provider.

I’ve gone back and forth on using TypeId or named plugins using a string. Mainly switched to the named variant to support each oauth provider lookup by name.

If you have any suggestions for making it better, let me know!

Big enum?

If the library wasn't open for extension, an enum could work. With the currently model, users can write their own plugins, bring their own storage provider, or even write an email consumer that reacts to events from the EventBus - all without needing to upstream their changes to torii and torii-core.

What about providing a plugin registration macro that generates an enum that can be provided to the library.

So it’s not open for extension?

JavaScript definitely has a few such OpenAuthJS, Better-Auth, and Next-Auth.

PHP Laravel, Ruby on Rails, Python Django, Elixir Phoenix all have some ways of doing this, but are usually baked into the framework.

Others usually end up as a standalone service like Keycloak, Authelia and more.

Thanks.

Sounds like there's not much like this for Java or C#.

I think the most similar you'd find for Java are Shiro [0], Java Authentication and Authorization Service (JAAS) [1], and pac4j [2].

0: https://shiro.apache.org/

1: https://docs.oracle.com/en/java/javase/22/security/java-auth...

2: https://github.com/pac4j/pac4j

Thanks!