Auth0 configuration API doesn't specify database connection for auth0 application

[ahmeddwaheed]

The config object in the types.ts file doesn't have a parameter for the db connection of auth0 and it should be included as the auth0 API documentation shows in their official documentation

as shown in the config of auth0 object it doesn't have a connection option to determine which db the user can use if a single application is using multiple

// Details of the Auth0 application
auth0: {
    // Get these from your Auth0 app dashboard
    audience: string,
    clientId: string,
    domain: string,
    // This will be custom to your application, e.g. 'given_name profile'
    scopes: string
},

[ahmeddwaheed]

I added this pull request to fix this issue https://github.com/jbreckmckye/electron-auth0-login/pull/38

[jbreckmckye]

Hi Ahmedd, I'm not really familiar with this parameter. I don't use Auth0 a great deal nowadays.

Can you explain why someone using this library would need to supply connection? What is the difference for the user?

[ahmeddwaheed]

Here's the implementation for auth0-spa-js which has the connection variable to be used if needed, line

[jbreckmckye]

I'm still not 100% sure I follow. Maybe this is because I'm not familiar with more recent Auth0 features.

You keep referring to databases, but I can't see anything to do with databases in those documents. Just external auth providers. Is that what you mean by 'database', here?

I don't think those two m2m application configs really tell me enough to understand your request. I'm not sure what a 'Live Collection Service' is.

Can you explain what the difference is, for the user? Maybe talk me through what the user sees as they authenticate, with or without a connection, as it will help me understand the scope of the feature request and its priority

[ahmeddwaheed]

The end-user won't be affected, this comes with a benefit for your app development, in cases such as you have one application with multiple database connections (for different users) -Auth0 database connections Documentation- so If you have multiple environments sharing the same Auth0 application, this application is connected to different user databases for the different environments, in a scenario like this you can define a connection field in the /authorize request to use the right database based on the environment your service is currently using, now you have your users grouped as production users and testing using a single application. This community thread is sharing a similar problem.

Sorry if the example of Live Collection Service got you confused, It was just an m2m app I use with this name, connected to two databases [Auth0 Management Api, Something-collection] and I route my users to the one they should authenticate with, based on their group. I deleted it to not confuse anyone reading this thread.

I also referred to the implementation of auth0-spa-js which takes into account this field to be used for authenticating one app with multiple databases.

[jbreckmckye]

Hi Ahmedd, thanks for getting back to me.

I can understand now what your database feature is about - it's having multiple repositories within your Auth0 account for users in different 'contexts'.

Do you know where it's documented that you can key these using the connection field? I can see that this string can be used to specify social login providers, but not that these are used for databases too. Is there a thread or doc you can share?

One thing I would need to check is that if a social login provider is passed, this doesn't break the auth flow. Right now that works on parsing the URL after a navigation event. If it doesn't work I'd probably need to clarify that with users.

[ahmeddwaheed]

Based on the official documentation of Auth0 APIs#login (social section) https://auth0.com/docs/api/authentication#login indicates that the connection field is used with users from different social providers ie; [github, twtitter, google-oauth2] and these providers, in the end, are using different databases under these names and you can navigate users with the connection field. This is the same idea of using a non-social database/s which is explained in this section which says:

connection: (REQUIRED) | The name of the database connection configured to your client.

Which didn't explain that your connection must be a social one.

Also the Signup section, it says that you can use the connection field as the

The name of the database configured to your client.

But it's not specific to be used only in this situation. It's not explained directly but with this reference too, which says

In Auth0, you can associate different connections (methods of authentication) to specific applications, or directly to a tenant (as domain connections). When a user logs in, one of these connections will need to be selected as the one to use.

Also, I tested the change in different scenarios for a project I'm working on. I needed to make sure that it will be backward compatible with package users so this is why the field isn't required in /authorize requests as while it is optional the connection fallbacks to the default database when you don't specify it.

[jbreckmckye]

Based on the official documentation of Auth0 APIs#login (social section) https://auth0.com/docs/api/authentication#login indicates that the connection field is used with users from different social providers ie; github, twtitter, google-oauth2

Indeed it does. One concern I have is whether specifying a social provider will break the auth code mechanism. We rely on the browser window finishing in a state with the auth code serialised into the URL. So I would need to check this.

and these providers, in the end, are using different databases under these names

This has been the part that has thrown me off. You've written about this as though social signin is implemented in the same way as connecting to e.g. some MySQL instance exposed on the internet. Hence the confusion.

It might be that the string can be used for either social login or set up database connections. But "in the end" I am doubtful they have the same implementation. So when you submitted an issue and PR talking about 'databases' in the context of something documented for social login, I was a little surprised.

It sounds like what you mean, is that custom database connections are named via a developer-supplied key, and that key can be passed as the connection field, along with the names of social login providers. Is that correct?

The reason I want to check is that although connection is used for both purposes, I've yet to see API documentation that confirms they are used for both in the /authorize request.

Also, I tested the change in different scenarios for a project I'm working on.

And did you find that connection would discriminate between users in one database connection, and another?

[ahmeddwaheed]

This is not related to any external databases on the internet, the database terminology I frequently use refers to Auth0 databases. Auth0 exposes the developer to switch connection to a social database or a non-social database by connection field in the authorization flow, a non-social database is like the default one created by Auth0 UserName-Password-Authentication or any database of your creation inside Auth0 from + CREATE DB CONNECTION button

It also could be a custom database created by a developer-supplied key under any name within Auth0 so that users can be authenticated via your login scripts.

FYI; I tested the auth flow with a connection set to social apps like google-oauth2, and it's working fine

In the end, what I mean is that you will need the connection field to do that switch to authenticate users based on any connection you might have wether a social or non-social one as long as it's within your Auth0 connections

[jbreckmckye]

Cool, this sounds pretty straightforward then. When you used the social connection, did the library get the auth token OK?

[ahmeddwaheed]

Yes, it's working fine the same as the normal login flow

[jbreckmckye]

@ahmeddwaheed Actually, I just realised something - we already support passing arbitrary parameters to the /authorize call

You just need to pass some login.authorizeParams into the config. These are then spread onto the query.

See here: https://github.com/jbreckmckye/electron-auth0-login/blob/master/src/adapters/authWindow.ts#L42

This is documented here: https://github.com/jbreckmckye/electron-auth0-login/blob/master/docs/setup.md#configuration-options

I was wondering why we didn't just let the user pass custom parameters... then I remembered, we do!

This is what happens when you only touch a library once a year.

[ahmeddwaheed]

I tested it and it works, I think I missed that too, my bad. Anyway thank you for your time and interest to crack this issue up, you can close the issue now

[jbreckmckye]

No worries, I completely forgot about this! It was a feature I must have ported during the rewrite, without remembering