I’m not going to cover the steps involved in creating an app registration. This is covered, in detail, in the Microsoft documentation. In this article though, I want to point out some important things.
The platform enables the generation of two token verions, v1.0 and v2.0. The tokens generated by the platform look very similar but the difference in versions determines what claims are included. At a high level, v1.0 tokens are for Azure AD only applications, while v2.0 tokens can be used to support both Azure AD and consumer accounts such as Facebook and Twitter. Configuring the type of tokens accepted can be configured using the app manifest and by setting the accessTokenAcceptedVersion setting. Values of null and 1 result in v1.0 tokens, and 2 results in v2.0 tokens. You can use JWT.ms to view both v1.0 and v2.0 tokens as examples. If you change the token version in the app manifest, don’t forget to click Save.
When you create app registrations for client applications, you will use a different set of configuration values, than when creating for a Web API. Here is a summary of those.
Scopes are defined in the format of resource/scope. Scopes have shortcuts as well, such as in the Microsoft Graph, where User.Read is the same as https://graph.microsoft.com/user.read. In order to add scopes to your own Web API app registration. Select Expose an API in the application registration.
api://{clientId}) by selecting Save and Continue.Scopes also appear on the consent window that’s presented to users of your app. Therefore, provide the corresponding strings that describe the scope:
So far, we have learned the basics of app registrations for Web API apps and looked at scopes and how to create them. In the next post, we look at how to configure your code to use the Microsoft Identity Platform, as well as protect your API endpoints and validate scopes.