multiple oauth2 providers at once?

[grmkris]

how to configure the plugin to allow oauhth2 logins from google, twitter, facebook. ?

[thgh]

Not sure if it would work, but something like this could:

buildConfig({
  ...,
  plugins: [
    oAuthPlugin({
      mongoUrl: process.env.MONGO_URL,
      clientID: process.env.OAUTH_CLIENT_ID1,
      clientSecret: process.env.OAUTH_CLIENT_SECRET1,
      authorizationURL: process.env.OAUTH_SERVER1 + '/oauth/authorize1',
      tokenURL: process.env.OAUTH_SERVER1 + '/oauth/token',
      callbackURL: process.env.ORIGIN + '/oauth/callback1',
      async userinfo(accessToken) { return { sub: "facebook123" }  },
    }),
    oAuthPlugin({
      mongoUrl: process.env.MONGO_URL,
      clientID: process.env.OAUTH_CLIENT_ID2,
      clientSecret: process.env.OAUTH_CLIENT_SECRET2,
      authorizationURL: process.env.OAUTH_SERVER2 + '/oauth/authorize',
      tokenURL: process.env.OAUTH_SERVER2 + '/oauth/token',
      callbackURL: process.env.ORIGIN + '/oauth/callback2',
      async userinfo(accessToken) { return { sub: "google123" }  },
    }),
  ]
})

[thgh]

Feel free to reopen if it didn't work

[Samtropic]

Hello, I've just tested the use of multiple providers. Unfortunately only the last definition of oAuthPlugin is valid and used.

[thgh]

Hmm, issue is probably related to the "name" of the strategy, "oauth2" in this case

passport.use('anotherstrategy', strategy) can be used to rename it over here:

payload-plugin-oauth/src/index.ts

Line 188 in cbd8a02

passport.use(strategy)

PR welcome!

[Samtropic]

Happy new year Thomas !
I don't think it's related to the name of the strategy (and I actually tested it, giving it a name through the plugin's options).
It seems instead being related to the fact there is only one instance of the plugin running and it's using the last options defined.

[thgh]

Thanks, best wishes to you!

Did you also update line 188 and rebuild the plugin?

Do you mind trying out payload-plugin-oauth@next ?

• It assigns names to each strategy and sets up routes per strategy
• It passes authorizePath to each button, instead of rendering the same button twice.
• New option: buttonLabel so you can differentiate between buttons.

[Samtropic]

Thank you!
I modified the line 188 as passeport.use(strategy.name, strategy). The strategy.name is an option defined in the oAuthPluginOptions configuration. I did not rebuilt the module but instead modified directly the JS file when testing.

What is the plugin you are referring to ? I didn't find it, did you mean this one imCorfitz/payload-plugin-oauth-apps ?

[thgh]

npm install payload-plugin-oauth@next
or
yarn add payload-plugin-oauth@next
(no need to update JS code, it will replace the existing plugin, you can always go back by installing npm install payload-plugin-oauth@latest)

It's a special version with experimental support for multiple providers

[Samtropic]

Oh sorry I didn't see the tag ! My bad. Sure I'll give it a try thank you !

[Samtropic]

Hi @thgh , I finally tested the @next version of the plugin (sorry for the delay). This is working great thank you.

I had to make sure that the _verified property is set to true when returning the user data.

async userinfo(accessToken) {
        const response = await fetch(
          new URL(process.env.MICROSOFT_OAUTH_USERINFO_ENDPOINT || ''),
          { headers: { Authorization: `Bearer ${accessToken}` } }
        );
        if (!response.ok) {
          throw new Error(`Erreur de requête: ${response.statusText}`);
        }
        const jsonResponse = await response.json();
        console.log(jsonResponse);
        const user = jsonResponse;
        return {
          sub: user.mail,
          username: user.displayName,
          email: user.mail,
          _verified: true, // If not set to true or not set at all, this make the user as not logged in unless you've previously ( before the oAuth sign-in) created it with credentials + email verification (which actually makes the _verified property to true in db)
        };
      },

Have a nice day !

[bote795]

is this now available in main branch? or still need to use that experimental tag? and if i wanted to be able to store the refresh_token, id have to edit and rebuild locally and import?

[thgh]

Still at the @next tag. Sounds like it's working, so will publish soon.

You could make a pull request where userinfo function receives an object containing the accesstoken + refreshtoken. Would be a breaking change so v2.

Or add it as 2nd param, would be backwards compatible.

[bote795]

thanks for replying. After I get the base working I will look into putting a pr with the refresh token change request. btw I am bearly trying this, but is this supposed to work with local payload login as well? or was that supposed to be disabled?