Azure-docs: Which OAuth2 flow is used in this QuickStart?

Created on 22 Oct 2020 · 4Comments · Source: MicrosoftDocs/azure-docs

I have two pieces of feedback:

It would be great if we described in a single sentence, what OAuth2 grant type this sample is using. One of the reasons this is important to developers is testing the sample using something like Postman. In order to get a token with Postman (or any other similar tool), you need to choose the Grant Type. I was able to test it using implicit flow however I needed to add a "web platform" in AAD, set a redirect URI, and enable the "access token" checkbox under the Implicit Grant. If you follow the sample and click the links at the bottom of the page it will take you to the app registration page where it says no such redirect is necessary. While this may be true for the sample to run, there is no way to test it (that I know of) unless you configure a redirect.
It would be very beneficial to have a section (or another page) describing how to test each sample using something like Postman. We have other samples where Postman is used to get a token when describing different flows for different products like the Graph.

The developer experience is great and the article is well written however when you built it, you want to test it and we have no guidance on how to do so. I would be happy to submit a PR on both points above as well. Cheers!

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: d6102ebf-9a84-413b-81f9-711f7e2ff9e1
Version Independent ID: 1a6dcb5b-cd4b-a09e-15ea-953cddf109f1
Content: Quickstart: Protect an ASP.NET Core web API with the Microsoft identity platform - Microsoft identity platform
Content Source: articles/active-directory/develop/quickstart-v2-aspnet-core-web-api.md
Service: active-directory
Sub-service: develop
GitHub Login: @jmprieur
Microsoft Alias: jmprieur

Pri2 active-directorsvc assigned-to-author develosubsvc doc-enhancement triaged

Source

jasonshave

👀1

Most helpful comment

@jasonshave Hi Jason - first, huge thanks for the offer of a PR. We need more like you. :1st_place_medal:

Regarding your call-outs:

The sample for this quickstart, a web API, does not itself use an OAuth2 grant type. A client app that wishes to access the resource API, however, _does_ use an OAuth2 flow to obtain an access token from the identity provider (the Microsoft identity platform), and may do so using one of the various grant types. In your case, Postman is the client app, and you're using the implicit grant to obtain an access token from the identity provider. As such, you had to configure your app registration to enable the implicit grant _for the client app_, Postman.
A "Test API access with Postman" how-to that we could point to at the end of API quickstarts and tutorials is absolutely a good idea. If it could be generalized and made short enough, we could even use an [!INCLUDE] and pull it in at the end of _any_ API quickstart/tutorial that's about protecting a web API.

This second item has a bit of a longer tail, however, so I'd like to ping you offline to discuss your offer of contribution. We'd close out this issue, open a work item in the content team's ADO instance, and I could work with you to get it in there.

Thoughts?

reassign:mmacy

mmacy on 26 Oct 2020

👍2

All 4 comments

@jasonshave
Thanks for your feedback! I have assigned this issue to the author who will investigate and update as appropriate.

JamesTran-MSFT on 23 Oct 2020

👍1

@jasonshave Hi Jason - first, huge thanks for the offer of a PR. We need more like you. :1st_place_medal:

Regarding your call-outs:

The sample for this quickstart, a web API, does not itself use an OAuth2 grant type. A client app that wishes to access the resource API, however, _does_ use an OAuth2 flow to obtain an access token from the identity provider (the Microsoft identity platform), and may do so using one of the various grant types. In your case, Postman is the client app, and you're using the implicit grant to obtain an access token from the identity provider. As such, you had to configure your app registration to enable the implicit grant _for the client app_, Postman.
A "Test API access with Postman" how-to that we could point to at the end of API quickstarts and tutorials is absolutely a good idea. If it could be generalized and made short enough, we could even use an [!INCLUDE] and pull it in at the end of _any_ API quickstart/tutorial that's about protecting a web API.

Thoughts?