Redirect URI should not be required for Confidential Client

[clairernovotny]

Some flows, like the On-behalf-of flow don't require a redirect URI, so that value shouldn't be required in the ConfidentialClient constructor.

[kpanwar]

You should be able to pass null and not run into issues.

[clairernovotny]

@kpanwar can that be documented? Right now the param comments say that it's required, so people may get confused

[kpanwar]

Sure! I will kee this issue open to track the work.

[htuomola]

Actually passing redirect uri as null causes an exception when calling AcquireTokenOnBehalfOfAsync(scopes, UserAssertion), on creating request params.

System.ArgumentNullException : Value cannot be null.
Parameter name: uriString
   at System.Uri..ctor(String uriString)
   at Microsoft.Identity.Client.ClientApplicationBase.CreateRequestParameters(Authority authority, IEnumerable`1 scopes, IUser user, TokenCache cache)
   at Microsoft.Identity.Client.ConfidentialClientApplication.CreateRequestParameters(Authority authority, IEnumerable`1 scopes, IUser user, TokenCache cache)
   at Microsoft.Identity.Client.ConfidentialClientApplication.<AcquireTokenOnBehalfCommonAsync>d__16.MoveNext()

I think it comes down to this, which won't work unless RedirectUri defaults to some valid uri:

microsoft-authentication-library-for-dotnet/src/Microsoft.Identity.Client/ClientApplicationBase.cs

Line 234 in d5026d5

RedirectUri = new Uri(RedirectUri),

Code itself:

var scopes = new[] {"https://graph.microsoft.com/user.read"};
var userTokenCache = new TokenCache();
var cca = new ConfidentialClientApplication(clientSettings.ClientId, null, new ClientCredential(clientSettings.AppKey), userTokenCache, null);
await cca.AcquireTokenOnBehalfOfAsync(scopes, GetUserAssertion(userInformation))

[jmprieur]

We need a redirect URL for the authorization code grant, but not for client creds, OBO, ...
The idea is to make it optional by adding overrides, or accept null and throw when using the authorization code throw.

[jmprieur]

@bgavrilMS : this one is poachable

[bgavrilMS]

@jmprieur - I propose that we make sure the docs emphasize where redirect URI can be null and fix the exception for OBO flow and client creds.

Alternatively, I can obsolete the calls requiring a redirectUri so that we can remove them in when we get rid of the -preview tag?

[jmprieur]

@bgavrilMS : I'd prefer the first option (allow null, fix the exception for Client credentials. Not sure for OBO?)
The alternative would touch the constructor … and most confidential client flow require the redirect URI. I would think OBO does?

[MSAppsDev]

Hi,
Is this fixed?

[bgavrilMS]

@MSAppsDev - no, the issue is still open.

[jmprieur]

@MarkZuber : done part of the confidential client builder based app configuration

[MarkZuber]

In 3.x, constructing with null will set the default redirecturi to be urn:ietf:wg:oauth:2.0:oob and that redirecturi will get used during any requests as needed.

I've added unit tests to explicitly cover this case in dev3x.

[jennyf19]

@MarkZuber just for confidential clients?

[jmprieur]

yes, just for Client Credentials, actually (daemon apps)
So the default replyUri for confidential client apps could rather be https://replyUriNotSet or something like that. For public client apps it's more subtil than that (do what we used to do)

[jennyf19]

Fixed in MSAL 3.0.0-preview release