auth0/auth0.net

Better support IHttpClientFactory in AuthenticationApiClient

yori-s opened this issue · 7 comments

yori-s commented

Checklist

  • I have looked into the Readme and have not found a suitable solution or answer.
  • I have looked into the API documentation and have not found a suitable solution or answer.
  • I have searched the issues and have not found a suitable solution or answer.
  • I have searched the Auth0 Community forums and have not found a suitable solution or answer.
  • I agree to the terms within the Auth0 Code of Conduct.

Describe the problem you'd like to have solved

While AuthenticationApiClient can be used with IHttpClientFactory (#498), I believe it loses the benefit of the jwk cache in IdTokenValidator.

Describe the ideal solution

If IdTokenValidator were public and exposed as a ctor arg in AuthenticationApiClient, could get the best of both worlds.

Alternatives and current workarounds

No response

Additional context

No response

frederikprijck commented

Thanks for reaching out. Can you elaborate a bit more on your use-case so I can better understand what's asked here?

Note that we have no intention to make IdTokenValidator public, as we do not want to expose a reusable way to validate tokens (this is not the intention of this SDK), but happy to try and understand your use-case and see if we can and should change anything.

yori-s commented

Thanks for looking into this!

In my current use cases (so far - it's a new project), I just want access tokens and don't need id tokens:

  • client_credentials to get a token for the management api (works great)
  • password (with a client secret) for pre-production uses
    • dev convenience to get an access token for use with curl/postman
    • down the road, load tests that take username/passsword pairs in a gatling feeder

I'd be good to go if there was an option to disable id token verification for password grants, but that seems to be off the table, at least judging by #372.

Right now, I'm using [I|HttpClient]AuthenticationConnection vended from IHttpClientFactory, but thereby duplicating parts of AuthenticationApiClient.

In a perfect world, I'd like to be able to do something like the following:

services.AddHttpClient<IAuthenticationConnection, HttpClientAuthenticationConnection>();
services.AddSingleton<ISomeCacheAbstraction, ...>(); // ctor arg to AuthenticationApiClient
services.AddTransient<IAuthenticationApiClient, AuthenticationApiClient>();
frederikprijck commented

Thanks for that context. I am not sure I understand why you want to disable the id token verification, is there something not working about the id token verification that makes you want to disable it?

I'm also not sure I understand why does the user needs to use their username and password if you don't care about their identity (ID token). Why not use the client credential grant in this case as well (assuming they are authenticated and authorized for the API that retrieves these tokens)?

yori-s commented

In the normal course of things, a user authenticates via a spa, which then gets an access token for my api (the spa is also under my control).
A custom action augments the api access token with a few claims from the user profile so the api doesn't have to consult a user info endpoint to make authorization decisions.

I'm using the password grant to generate the api access token without the involvement of a real user.
If there's a better way to get the access token - that would be great!

Regarding id token verification, I haven't encountered any functional problems, but didn't like the overhead of the jwk cache miss when paired with short lived HttpClients created by IHttpClientFactory.

frederikprijck commented

Whenever a user is involved, we return a users identity through the id token. If you dont want that, you want to look into integrating the client credentials flow, you can use an action to add any additional claims using client credentials as well, see https://auth0.com/docs/customize/actions/flows-and-triggers/machine-to-machine-flow/event-object

Regardless, I dont see any change we need to implement to support your use-case, I believe it should work as is in different ways (with or without an id token).

Closing this, but happy to continue the conversation or reopen as needed.

yori-s commented

Thanks for the tip on the m2m trigger - having access the request body makes it an ideal backdoor token generator 😄

The main disadvantage I see compared to the password grant is action and m2m token quotas; this project was promised an enterprise subscription, so seems like a reasonable tradeoff.

While I'm disappointed about IHttpClientFactory, I'm good with closing this ticket.

Thanks again for your help!

Hawxy commented

Regarding id token verification, I haven't encountered any functional problems, but didn't like the overhead of the jwk cache miss when paired with short lived HttpClients created by IHttpClientFactory.

@yori-s FYI, you might want to look at the package I built for this, I integrate with IHttpClientFactory but keep the clients as singletons.

  • 👍1