Scenario: A web app that authenticates users and calls web APIs
Learn how to build a web app that signs users in to the Microsoft identity platform, and then calls web APIs on behalf of the signed-in user.
This scenario assumes you've already completed Scenario: Web app that signs in users.
You add authentication to your web app so that it can sign users in and call a web API on behalf of the signed-in user.
Web apps that call web APIs are confidential client applications. That's why they register a secret (an application password or certificate) with Azure Active Directory (Azure AD). This secret is passed in during the call to Azure AD to get a token.
Adding sign-in to a web app is about protecting the web app itself. That protection is achieved by using middleware libraries, not the Microsoft Authentication Library (MSAL). The preceding scenario, Web app that signs in users, covered that subject.
This scenario covers how to call web APIs from a web app. You must get access tokens for those web APIs. You use MSAL libraries to acquire these tokens.
Development for this scenario involves these specific tasks:
- During application registration, you must provide a reply URI, secret, or certificate to be shared with Azure AD. If you deploy your app to several locations, you'll provide a reply URI for each location.
- The application configuration must provide the client credentials that were shared with Azure AD during application registration.
If you're new to identity and access management (IAM) with OAuth 2.0 and OpenID Connect, or even just new to IAM on the Microsoft identity platform, the following set of articles should be high on your reading list.
Although not required reading before completing your first quickstart or tutorial, they cover topics integral to the platform, and familiarity with them will help you on your path as you build more complex scenarios.
Move on to the next article in this scenario, App registration.
Submit and view feedback for