Consent not handled well by client app

[bgavrilMS]

Please provide us with the following information:

This issue is for a: (mark with an x)

- [x] bug report -> please search issues before submitting
- [ ] feature request
- [ ] documentation issue or request
- [ ] regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce

1. Login a user in client app. Notice embedded browser used.
2. Add an item

Actual: browser pops up for consent. Then failure because of bad redirect uri Expected: client app should not do Process.Start for consent. Perhaps it should call AcquireTokenInteractive and use .WithPrompt(Prompt.Consent)? This will avoid redirect uri issues and inconsistent browser experience. In any case, server app should not just assume client app's browser settings.

[jmprieur]

Which folder is this @bgavrilMS ? I cannot repro this?

[bgavrilMS]

This folder 2, the code is here: https://github.com/Azure-Samples/active-directory-dotnet-native-aspnetcore-v2/blob/master/2.%20Web%20API%20now%20calls%20Microsoft%20Graph/TodoListClient/MainWindow.xaml.cs#L206

[jmprieur]

@bgavrilMS this is a bit more subtle than that the consent is for the tenant admin to consent for the web API to call the downstream web API in multi-tenant scenarios. if you use the sample in single tenant cases, or for the tenant where your app was registered, all is good. but if you sign-in a user from a different tenant, the service principal of the web api will be created on the fly, but the user, or sometimes the admin will need to consent for the web API to call the downstream API (Graph) on behalf of the user. This is a provisioning thing. This is often seen in services as a sign-up page. This way of doing was recommended by Adrian and Chiung. The alternative is to provide a PowerShell script to tenant admin to install the application in their tenant