Enable Service Principal Registration at Permission Scope Approval Time with SPFx 1.15.2

With SPFx 1.15.2, a new feature snuck in that allows you to enable service principal registration when you are approving the permissions of the app. If you have ever had your SPFx solution talk to an AAD secured API, you know that not configuring the App Registration in the customer’s tenant can cause problems. Historically, you had to create a URL or some way for the user to sign in separately in the browser to route the user through the consent process for the App Registration.

However, with SPFx 1.15.2, Microsoft has streamlined this process. In your package-solution.json file, there are two new properties appId and replyUrl that you can add to each permission you request in webApiPermissionRequests that allows you to specify the id of the App Registration and a URL that the user is redirected to when the registration is complete.

Here’s an example of a registration:

    "webApiPermissionRequests": [
      {
        "resource": "My API",
        "scope": "user_impersonation",
        "appId": "cff90b76-1822-488f-b9a8-0e7524819c21",
        "replyUrl": "https://api.mycompany.com"
      },
]

Note that the replyUrl must be listed in the Redirect URIs section of the Authentication section of your App Registration. If you don’t have any platforms registered here, add a platform and choose Web. You can then specify the URL.

Build your SPFx package and add it to the App Catalog. To test this, you will need to remove any existing API permissions that were approved on the tenant along with the App Registration in AAD. If you are trying this on a new demo tenant like I did. I noticed I got a few errors during the process and I had to wait a few minutes after the App Catalog was created. If it fails the first time, remove the package and start the process over again.

After you add it to the modern App Catalog, click the Go to API access page. Select your API and click Approve. You will then see the consent request. Accept the permissions it requests and you will be redirected to your replyUrl. The permission should now be approved in Azure Active Directory.

You’ll notice that only basic permissions have been requested. My API actually requires additional permissions, but they don’t show up in the list when I look at the Enterprise Application permissions tab.

If I click on Grant admin consent button, I can then approve those additional permissions requests.

When thinking about this, I came to the conclusion that the scope parameter in webApiPermissionRequests represents the scope that you are granting the SPFx service principal. However, your consent flow needs another set of scopes that you are granting to it. For example, I want my API to have access to GroupMember.Read.All but I don’t want the SPFx principal to have it.

While this new capability is a huge step forward, it doesn’t eliminate the manual consent flow that’s still required. However, it does make the initial registration a lot easier. I’m excited to see where this can go.