Start a wish list for an upgrade to ueberauth

[hassox]

There's been a few points of feedback I've been getting on Ueberauth. It feels like we have a sufficiently diverse community now to really dial in on what would make Ueberauth amazing.

The couple of major things that come to mind are:

1. Remove the forced reliance on Plug. Constraining Ueberauth to only work through plug makes it inflexible. It seems that we should be able to change the behaviour so that conn is not included in the main authentication part. It should receive some parameters instead so that it can be used outside of the case of a plug. Ueberauth can then provide a plug that makes use of the defined behaviour to do the right thing.
2. The individual strategies need to be updated to handle 'token' auth rather than the standard browser flow. Although this is currently possible, the ueberauth_* libraries do not support this.

I'd love to start fleshing these ideas out into something more resembling a spec and wondering what thoughts others have about it.

[yordis]

Just for linking back to this:

• Token based workflow: Add token base workflow #50
• Configuration Reader: Add reader module for Strategies configurations #51

#51 the basic idea is that I can swap how I read the configuration for the strategies.

For example

config :ueberauth, Ueberauth,
  providers: [
    facebook: {
      Ueberauth.Strategy.Facebook,
      MyApp.Ueberauth.ConfigurationReader # Notice this, it is not a Keyword list anymore
    }
  ]

# or even the whole thing so we can add and remove the providers dynamically
# for sure, somebody needs to implement some mapping with the modules
config :ueberauth, Ueberauth,
  providers: MyApp.Ueberauth.ConfigurationReader # Notice this

# or I would promote the configurations to the submodule itself
# I think this embrace more Elixir way rather than allocate all the config
# to the main module, 
config :ueberauth, Ueberauth.Strategy.Facebook,
  key: :value

The configuration reader should implement some protocol

defmodule MyApp.Ueberauth.ConfigurationReader do
  @typespec call(atom()) : Keyword.t()
  def call(provider_name) do
    # do whatever you want, either load from database
    # or just another config or some hardcoded config
    # or read from ets (database anyway  😄 )

    keyword_list_config = [ ] # as long as we return the same data structure
  end
end

What this will allow me to do is be able to load configurations from the database, business like Auth0 allow you to do that so we can extend Ueberauth to be some long running OTP app where you just change the configurations on the database so when some keys or anything becomes invalid we do not need to release or at least stop the server and load the new configuration, everything could be done at the database layer

[yordis]

btw, the idea is not calling the module reader once for the configuration because then we will have to restart or end the process anyway 😅

I was thinking on create some GenServer per provider as well so we could save the configurations inside and we can reload the process for that provider when we need it.

Also that way, if one of the providers is down and something happens with it, it will no affect other pieces of the application.

I will try to draw some diagram for this, I has done something similar with StrawHat.Cashier (payment gateway for payment gateways)

[rmoorman]

@hassox , I don't know if this is the right place to discuss additional items for your wish list, but I am wondering how to have one (phoenix) application support multiple ueberauth configurations.

Specifically with preferably one http endpoint I would like to build a multitenancy environment which would need to use multiple dynamic configurations for ueberauth. I think multiple configurations are needed as each tenant is assigned a hostname and each tenant could have a different ueberauth configuration (e.g. based on database records) so that customer A can configure his app through a (web) gui to use google and facebook (using his credentials from the respective providers), while customer B could use only a microsoft auth provider (with client credentials from azure ad).

Any idea's how that would fit into ueberauth? :-)

[yordis]

@rmoorman that is in the radar, #51

[rmoorman]

@yordis how would you picture #51 working in a situation where multiple configurations (each with differently configured providers) would exist and each configuration should be applied based on the hostname for example?

I mean, wouldn't one still need some kind of discriminator and/or some restructuring/additional functionality within ueberauth to facilitate this scenario? (mainly for selecting a configuration as needed; could also imagine that in case the configuration is flat / there is no discriminator, the configuration at hand is the default in any case ..)?

Wouldn't you see the hows and wheres of configuration loading and storage as a different concern? Something separate from using the configuration, abstracted away behind a protocol maybe?

I am personally not that well versed with ueberauth (yet) as I am a bit new to elixir/phoenix, but for me both things (a configuration reader and having a way to use choose and use different configurations at runtime) seem to be related but still seem to be different things.

[yordis]

@rmoorman the idea is to support Configuration loaders that you can pick your strategy ...

[rmoorman]

@yordis so the idea also includes altering the way of strategy lookup, making the context data (e.g. plug connection) available to the loader and having the loader responsible for returning a configured strategy? That could be a way to accomplish that I guess.

[yordis]

@rmoorman yes

[alejandrodnm]

I would love to see Token based workflow #50 implemented. I'm pushing in my department to start using Elixir and this is a must, we do internal web based tools and they are all SPA with google auth implemented client side.

So right now we have two choices, implement like what @yordis has done in #50 or use the fork (already 7 commits behind) referenced in #20.

[yordis]

@alejandrodnm here is my 2 cents on what to do right now.

My solution was independent of Plug.Conn because I was using Absinthe so I didn't have access to the Plug.Conn.

The fork solution wouldn't work for me because they do have dependency with Plug.Conn.

So, do you have access to Plug.Conn, then use the fork, if not, then do what I did, specially that it is for one strategy.

[zacck-zz]

Watching this... keen on token-based workflow

[yordis]

Don't need to do the configuration reader, by opening the API should allow us to pass the configuration rather than keep relying on Ueberauth to adapt to use cases.