Get bearer token from Azure for protected .net core 6 API

Question

I'm working on a backend service for a web application in .NET Core 6.
I was reading this article to decide my approach: https://learn.microsoft.com/en-us/azure/active-directory/develop/authentication-flows-app-scenarios
There is a frontend app developed separately which should communicate with my API eventually, so I figured that I should go with Protected web API.
So if I understood correctly the frontend app should handle the user login and token acquisition, I only need to verify that token.
I created the default WeatherForecast application and started following the documentation: https://learn.microsoft.com/en-us/azure/active-directory/develop/scenario-protected-web-api-overview
I exposed that 1 scope mentioned in there and no app roles. It now returns the code 401 when I try to test it in Swagger which is expected but how do I acquire a Bearer token for testing it in Postman?
I know that I can configure Swagger to use login on the UI but it seems that everything needs a redirect uri.
Do I need to set a redirect uri anyway to be able to test it?
Or is this the right scenario for me?

I've never worked with the Microsoft identity platform before and I don't really have much experience with .NET Core either.

Thanks for any help

Answer 1

Hello @CsK and thanks for reaching out. Great to see you could find a solution to your issue. I'm adding my answer to cover each of your questions and add some more content that may help you and others from the community:

1. I exposed that 1 scope mentioned in there and no app roles. It now returns the code 401 when I try to test it in Swagger which is expected but how do I acquire a Bearer token for testing it in Postman? You can import and use the Azure AD v2.0 Protocols Postman Collections
2. I know that I can configure Swagger to use login on the UI but it seems that everything needs a redirect uri. You need to set the appropiate Swagger redirect uri (E.g. https://app.swaggerhub.com/oauth2_redirect)
3. Do I need to set a redirect uri anyway to be able to test it? Yes it is
4. Or is this the right scenario for me? It is. The basic setup is to acquire an id token in order to get logged-in your frontend app to later acquire an access token to get authorized by your backend app. Out of the box each app expects tokens containing their app/client id in the token aud claim. Alternatively, and usually in the backend, you might enable validation of access tokens issued to another apps. That's where options.TokenValidationParameters.ValidAudience comes handy.

For more information about frontend to backend setups please take a look to:

• Scenario: A web app that authenticates users and calls web APIs
• Scenario: SPA that signs in users and calls web API

Let us know if you need additional assistance. If the answer was helpful, please accept it and complete the quality survey so that others can find a solution.

Answer 2

the login process is pretty simple. you register your application with the oauth server which defines several import attributes

1) clientid - a guid that identifies your app
2) tenantid - a guid that defines you authentication domain
3) scopes - defines application roles
4) reply url - the url the login server redirects to after login.

to get a token, your app opens the login server in a webbrower (or redirects if hosted in a browser) passing tenantid, clientid and desired scope on the url. the oauth server logins the user, redirects back to the reply url passing an id token (and possibly a refresh token). the code behind the replay url will typically validate the token. if a website that will call an webapi requiring an access token, typically it will store a refresh token in. cache keyed by the userid. when required, it will lookup the refresh token, and pass it to the login server to get an access token. it can then use this access token as a bearer token.

you can configure bearer token support in the swagger-ui. then you create a webapi login action that return a bearer token. in the swagger ui, you execute the login and then copy the returned token. on a request requiring authorization (a popup occurs that asks for the token).

if you don't create the login api, you can use postman to call the oauth server directly and get the access token to use.

Answer 3

the access token has some graph api scopes. but what scope did you define for your application api in azure ad?

when you selected expose an api in azure ad, you should have defined a scope. you should include this scope when requesting the access token

Answer 4

Turned out my approach was wrong. This post helped me finding the solution: https://stackoverflow.com/questions/71053269/scope-is-not-being-added-to-access-token-returned-from-azure-ad