Closed kmb385 closed 2 years ago
Thanks for the feedback! I have assigned the issue to the content author to investigate further and update the document as appropriate.
Awesome! Glad to provide any additional feedback on the item. Thanks for looking into it.
Great issue writeup, @kmb385. We're currently building out new multi-article tutorial series for this and other application types/scenarios, and calling the protected API will absolutely be included in our "Protect an API" tutorial series.
@Dickson-Mwendia I'll leave this open for you review and perhaps close for now, but @kmb385 was kind enough to include a full step-by-step for testing with Postman that we can likely leverage in our upcoming tutorials. That was above-and-beyond the call of duty but is very much appreciated, @kmb385 - thanks again! 🥇
@mmacy My pleasure! Thank you for the excellent learning materials! I'll actually become part of the team at Microsoft on February 14th and these quickstarts have been so helpful as part of my ramp up!
@kmb385 Great! One quick fix to your issue description:
@Dickson-Mwendia We'll need to balance the convenience/ease of adding a redirect URI to the same app registration as the web API vs. creating a new app registration for Postman (to act as the client app). Best practice is to use separate app registrations for client and resource, so having people use the same app reg for both while following a tutorial risks sending the wrong message.
Having said that, what we could do is write _Test your $APP_TYPE
's [authentication
| authorization
] with Postman_ how-to articles, and the "Register Postman as a client application" section could be an INCLUDE that we use for the tutorial series.
@mmacy Thanks for pointing out the single registration situation. I overlooked that and hadn't recognized that both Apps and their clients are registered underneath the same mechanism in Azure Active Directory. This morning I walked through the process and have what I believe are some pretty decent updated instructions. If you would like, I can share them, but thought I would ask first so I didn't clutter up your team's workflow.
I'll take it the heart means share! Here they are...
Here are updated instructions which attempt to walk through registration of the client application.
After registering, exposing and protecting the ASP.NET Core web API an authorized client of the API can now send it requests. A client might be any other piece of software, such as a Single Page Application or desktop application that needs to call the API. Since access to the web API is restricted by the established scope, it will require clients that call it to be registered with the Microsoft Identity platform via a separate app registration and granted the scope.
Postman, is a popular application that developers use to test API calls, which can be used as a client for testing authorized calls to the API protected by the Microsoft Identity platform.
After the client has been registered and assigned the appropriate permissions, you’ll need to create credentials the client can use to obtain a token to access the web API.
After these configurations are in place within Azure Active Directory, you’ll have everything required to successfully make an authorized request to the API via Postman.
@kmb385 Wow! That's awesome. And, yes, the heart meant share - here's what I had written but failed to hit the Comment button:
@kmb385 Absolutely, please do share, and don't worry about cluttering up our workflow. We appreciate all constructive criticism and feedback, and especially appreciate contributions like yours. There are several ways to contribute to docs, including contributing directly to the MicrosoftDocs/azure-docs repo, but it's typically lower-friction (and thus quicker) to hack out ideas in an issue first and then migrate it to a full-on docs article(s).
@kmb385 We do have similar prior art here that we might leverage and/or expand to support custom web APIs and surface it in the identity platform docs:
I've added this work to our backlog (Microsoft-internal):
ID | Title |
---|---|
1765243 | [ISSUE][87179] NEW article: Test a protected web API with Postman |
I've also propped your steps from https://github.com/MicrosoftDocs/azure-docs/issues/87179#issuecomment-1029257381 to this Gist: How to test a protected web API with Postman
I'll now close this issue as we're tracking internally and will pull it off the backlog as resources permit. #please-close
Thanks again for the issue and the procedure! 🥇
This quickstart provides a quick synopsis of how to protect a web api with Microsoft Identity platform, however it lacks any description of how to securely call the api once the security scheme is established. Without these instructions the learner will always encounter 401 errors when sending requests to the API or they will need to do additional research to learn how to obtain an access token to pass with the request.
After following the instructions in the quickstart, I needed to complete the following steps to make an authorized call to the protected web api that was provided as an example.
Additional Azure Configuration: Add Redirect URI
Additional Azure Configuration: Add Redirect URI
Postman Request Configuration
After these configurations are in place within Azure,the learner will have everything they require to successfully make a call to the API via a tool like Postman. Here are the instructions for configuring a postman request.
So there is quite a bit of extra work to make a successful request to the protected web api that is not covered by the quickstart and can be a little confusing when completing it. At a minimum I would recommend linking to any pre-existing documention that contains similar instructions. Otherwise, its going to leave the learner unclear as to whether they have properly configured the application and the service, which doesn't create a nice onboarding or first experience with an otherwise awesome product.
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.