ClientBuilder should not require redirectUri

[VictorioBerra]

I need to use a different RedirectUri in my app for different pages/features, and I am forced to define it when I call new ClientBuilder(...).

Due to this, I cannot create an interface that I can inject and mock as shown in the example with IDuoClientProvider.

Is there a way we can make the RedirectUri a parameter on GenerateAuthUri()? Would that not make more sense in general?

Detailed Description

See above.

Use Case

I have various pages in my ASPNET Core Razor Pages app that require the user to verify their identity via a Duo push, each feature/vertical slice of my app should have their own callback page.

Workarounds

None yet, working on it now. Maybe a central callback page that takes its own redirectUri... or a keyed service, each page will have a key that resolves the client that is built to target a specific redirectUrl.

[AaronAtDuo]

I am not opposed to this, but here is some history and notes for anyone that looks at this
The original reasons for making it a Client-level parameter: A) we were originally going to have an allow-list of redirect URLs so having it per-call would be fairly pointless B) it needs to stay consistent between the original request and the token exchange
A) is irrelevant since we never did that, B) could still be useful

If we decide to change this, we'd need to add it to both the "create request" and "exchange token" calls, and I don't think we'd have any way to ensure it's the same - thus transferring that burden to the developer + introducing a new failure case.
Also, we'd need to do the validation in both those methods.
Also also, we'd probably want to port the change to the other languages.

[VictorioBerra]

This is helpful information. As someone who is very familiar with OAuth2/OIDC I also thought it was odd that Redirect URLs did not need to be whitelisted on the Duo Admin side as you would normally for interactive clients.

[pshbot]

B) [the redirectUri parameter] needs to stay consistent between the original request and the token exchange
[...]
If we decide to change this, we'd need to add it to both the "create request" and "exchange token" calls, and I don't think we'd have any way to ensure it's the same [...]

As it currently is, in our app's implementation at least, I already supply the redirectUri parameter separately for the "create request" (GenerateAuthUri) and "exchange token" (ExchangeAuthorizationCodeFor2faResult) calls. This is because these two calls happen during separate web requests in our .NET web app:

1. The front end requests from our web API a Duo URI to redirect to. Our API creates a Duo client, supplying the redirectUri, and then calls GenerateAuthUri (after DoHealthCheck and GenerateState) to get the URI to return.
2. The front end redirects the user to the Duo URI, Duo auth happens, and the user is redirected to our redirectUri.
3. Our code at the redirect URI sends the data from the query string to our web API to validate. Our API creates a Duo client, supplying the redirectUri again, and then calls ExchangeAuthorizationCodeFor2faResult to validate the code.

So we already supply the redirectUri separately, since the Duo client instance doesn't persist across requests. Is ours not the common pattern?

At one point I tried not supplying redirectUri to the Duo client used for the ExchangeAuthorizationCodeFor2faResult call (since I don't need to generate an auth URI from that Duo client), but it seemed to fail. I assumed this was because part of the validation must check that the redirectUri in the Duo client matches what was supplied when the auth URI was generated.

Sorry if I've completely misunderstood!