Question: Is there a way to register multiple authentication clients?

[Poltergeisen]

We have a Microservice that is having some issues where I have multiple services trying to call AddAuth0AuthenticationClient with different clientIds.

Is there a way for this to work? To register a specific authentication client for a specific httpclient that I am trying to use? Am I missing something in the documentation?

Example:
In my Nuget package I try to configure the authentication specifically for this service:

            services.AddAuth0AuthenticationClient(opts =>
            {
                opts.ClientId = notificationsClientOptions.ClientId;
                opts.ClientSecret = notificationsClientOptions.ClientSecret;
                opts.Domain = notificationsClientOptions.Domain;
            });
            // configure Auth0 M2M for Notifications
            services
                .AddHttpClient<INotificationsClient, NotificationsClient>()
                .AddAccessToken(c => c.Audience = notificationsClientOptions?.Audience);

In another nuget package I try to configure the service for something else:

           services.AddAuth0AuthenticationClient(opts =>
           {
               opts.ClientId = settingsOptions.ClientId;
               opts.ClientSecret = settingsOptions.ClientSecret;
               opts.Domain = settingsOptions.Domain;
           });

           // configure Auth0 M2M for settings
           services
               .AddHttpClient<ISettingsClient, SettingsClient>()
               .AddAccessToken(c => c.Audience = settingsOptions?.Audience);

Am I doing this completely wrong? How can I configure both of these clients with different client ids/secrets in the same app?

[Hawxy]

That's going to be difficult as the current setup isn't designed to support multiple clients. I'll need to have a think about this.

[Poltergeisen]

Ah darn. Let me know how I can help. If you have a rough idea of how to implement it, then maybe I can do a PR

…

On Tue, Aug 23, 2022, 7:34 PM JT ***@***.***> wrote: That's going to be difficult as the current setup isn't designed to support multiple clients. I'll need to have a think about this. — Reply to this email directly, view it on GitHub <#10 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKVIV2O654AWXR4RM6357V3V2VUZLANCNFSM57NKY5XA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[Hawxy]

I'm looking into this and have some queries about your architecture. Generally how I see Machine-to-Machine clients being used is in a one-to-many fashion, so you'd have a single MtM client for a single system that's authorized to access x number of APIs (audiences). As far as I can tell your monolith uses multiple MtM clients and each one is permitted access to a single API, is that correct?

I'd understand the use of multiple MtM clients to maintain security isolation in separate systems, but that doesn't seem to be the case here.

[Poltergeisen]

Yes I believe that we may have implemented it backwards in a way. It's too late for me to change it now, but I can understand if you don't want to change your library to accommodate this edge case. Instead of my main applicationlike "users" which needs to contact "notifications" and "settings" having its own credentials, it seems like we have a client Id and secret for both notifications and settings alone. There is not an app or m2m setup specifically for users. I'd have to dig into it more to be sure but I was replacing a self written authentication service that we had to use this library since it was much more simple and reduced a lot of code.

…

On Wed, Aug 24, 2022, 3:59 AM JT ***@***.***> wrote: I'm looking into this and have some queries about your architecture. Generally how I see Machine-to-Machine clients being used is in a one-to-many fashion, so you'd have a single MtM client for a single system that's authorized to access x number of APIs (audiences). As far as I can tell your monolith uses multiple MtM clients and each one is permitted access to a single API, is that correct? — Reply to this email directly, view it on GitHub <#10 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKVIV2NY5KQH2BGXWOK7RHTV2XQANANCNFSM57NKY5XA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[Poltergeisen]

Honestly I'm not very well versed in authorization/authentication so I may not be explaining it very well either.

[Hawxy]

Instead of my main applicationlike "users" which needs to contact
"notifications" and "settings" having its own credentials, it seems like we
have a client Id and secret for both notifications and settings alone.
There is not an app or m2m setup specifically for users.

I'm guessing someone made the assumption that MtM clients are similar to SPA/Native clients and should be unique per service.

I had a quick run-through of the codebase to see if it'd be possible for me to add support for named clients so I could support this scenario, however it'd require a significant refactor. It's also not a scenario I want to promote so the time investment isn't really worth it for myself.

If you don't have the time to refactor your solution, I would just adjust one of the MtM clients to have API access to both services (Auth0 Dashboard -> Applications -> (settings/notifications client) -> APIs) and pass the same credentials down to both sets of extensions. If you get a InvalidOperationException at startup, let me know and I'll soften some of the internal checks.

[Poltergeisen]

Sounds good, I appreciate the help!

…

On Wed, Aug 24, 2022 at 6:11 AM JT ***@***.***> wrote: Instead of my main applicationlike "users" which needs to contact "notifications" and "settings" having its own credentials, it seems like we have a client Id and secret for both notifications and settings alone. There is not an app or m2m setup specifically for users. I'm guessing someone made the assumption that MtM clients are similar to SPA/Native clients and should be unique per service. I had a quick run-through of the codebase to see if it'd be possible for me to add support for named clients so I could support this scenario, however it'd require a significant refactor. It's also not a scenario I want to promote so the time investment isn't really worth it for myself. If you don't have the time to refactor your solution, I would just adjust one of the MtM clients to have API access to both services (Auth0 Dashboard -> Applications -> (settings/notifications client) -> APIs) and pass the same credentials down to both sets of extensions. — Reply to this email directly, view it on GitHub <#10 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKVIV2NAO3ODI7XVLXVLE53V2X7PBANCNFSM57NKY5XA> . You are receiving this because you authored the thread.Message ID: ***@***.***>