Two social (GitHub) connections for different scopes

[martincura]

Hi!

This seems to me like it could be a common problem but i have found no solution , sorry if there’s a similar thread because i couldn’t find it!

Basically the problem boils down to having 2 different GitHub Social Connections with different scopes.

Most of our applications need nothing more than just login through GitHub. It’s helpful that the default GitHub connection is already well set up and we even match with existing users that logged through Gmail with an extension.

But for a particular app (and possibly more in the near future) we want to ask for the repo scope. Thus we need a second connection of the same social service but the Dashboard doesn’t seem to allow this. Is there a way that i missed? It would be so much easier that what follows.

So i created a Custom Social Connection with OAuth for GitHub, but i can’t seem to get the email for accounts that work for the default gmail connection (as an aside, i’d say the “Fetch User Profile Script” documentation could do with some more love ). Moreover (and probably related to this), these accounts are not joined with existing user accounts in Auth0. This problem could probably be solved by knowing exactly how the default GitHub connection is set up so that i can just replicate it in the new one.

Any help?

Thank you in advance and if anything wasn’t clear don’t hesitate in replying!

Martín
Argentina

[stephanie.chamblee]

Hi @martincura,

You may be able to simplify this by using the same github connection and passing the additional scopes in the connection_scope param from the application that needs it when it makes the /authorize request.

You can read the details of this approach in this FAQ:

https://community.auth0.com/t/pass-additional-scopes-permissions-to-a-social-connection/56103

And in the docs:

https://auth0.com/docs/connections/adding-scopes-for-an-external-idp#2-pass-scopes-to-authorize-endpoint

[martincura]

I hadn’t managed to make it work but after you linked to it it finally did and solves our problem perfectly.

For completeness’ sake: we ended up including the connection_scope option when calling withAuthenticationRequired() in our <ProtectedRoute> component. After doing this, the /authorize URL seems to be appropriately modified (with a query param of the same name). It also seemed to work by adding an (undocumented?) connection_scope prop for <Auth0Provider>, but i’m not 100 % sure on that as i tried it quickly and moved on to something else.

Thank you!