Sp-dev-fx-webparts: Web API Authorization

[davidhartman]

Category

• [ X ] Question
• [ ] Bug
• [ ] Enhancement

Question

I was wondering how one might add authorization to the webapi calls. Because, right now it looks like the webapi calls are open to anyone, and in production I feel like we would want to limit that to only allow our applications to make calls to this webapi. I'm thinking along the lines of a custom action filter. But not sure how to implement that. Any suggestions?

Thanks for your contribution! Sharing is caring.

[waldekmastykarz]

If your APIs are hosted in Azure App Services then you could benefit of Azure App Service Authentication. Without changing your API code you could secure your APIs with Azure Active Directory. From the web part you would then follow the same approach as when connecting to Microsoft Graph using OAuth implicit flow.

If you host your APIs elsewhere then you would indeed need a custom security implementation. The key point here is to implement it in a way so that authentication to your APIs can happen in a non-interactive way. Otherwise AJAX calls will return redirect responses or HTML which require additional effort to be processed in the web part.

[davidhartman]

Thanks Waldek!

I was assuming that the APIs were going to be hosted in Azure, sorry I forgot to point the out. Please correct me if I'm wrong. One downside to having the APIs registered in AAD, would be that the client secret would need to be stored somewhere in the app, which could be hacked, right? Also using the Microsoft Graph approach the user would have to sign-in to AAD via the webpart and then the token would also need to be stored either in a variable in the app or in local storage, which again could be hacked, right?

Just trying to make sure that I understand the risks currently involved using those two solutions. Thanks again!

[waldekmastykarz]

Storing a secret in a client-side application would be a security issue indeed, which is why there is the OAuth implicit flow which is based on the publicly-known client id and the application URL. In the OAuth implicit flow no secret is used and the trust is established based on the URL of the application. In OAuth implicit flow you're not getting a refresh token but only the access token. When it expires the user has to reauthenticate with AAD to obtain a new access token.

Hope this clarifies it a bit.

[davidhartman]

Waldek -

Thanks! That definitely clarifies it a ton! Thanks for being so helpful!

[waldekmastykarz]

Glad to hear I could help :)

[davidhartman]

Waldek -

Sorry to bug you ... I'm able to get a bearer token and with it I can access the Microsoft Graph API successfully in my sharepoint framework web part. However, when I try to pass the same bearer token to my .NET Web API secured by AAD, I get an (401 Unauthorized) error. I have implicit flow enabled on both applications. Is there anything that pops out at you that might be causing this issue?

I should mention that I registered my sharepoint framework web part using apps.dev.microsoft.com, while I used portal.azure.com to register by .NET Web API with AAD. Not sure if that could be the source of the problem.

Thanks!

[waldekmastykarz]

Not at all! :)

Implicit flow is meant for use by client-side applications only. A .NET app capable of storing a secret, should use a regular flow with client id and secret. This is of course only valid for how you acquire the token. Once you have a valid token, it doesn't matter what type of client uses it.

Could it be that your token expired or that it doesn't contain sufficient permissions for what you're trying to do? Is the AAD with which you registered the application the same AAD as the one associated with your O365 subscription? If not then you might need to consent your application to be used on the O365 tenant.

[davidhartman]

Thanks Waldek! Both are applications are using the same tenant, and I just checked the token expiration and that doesn't appear to be the issue. It definitely could be a permissions issue with trying to communicate between the two applications. The client application that I setup in apps.dev.microsoft.com has Graph Permissions for User.Read, however, I don't have any application permissions. In apps.dev.microsoft.com it doesn't allow me to give my client application access to the .NET Web API web app. However, if i log into portal.azure.com and look at my active directory applications, my client app shows up but it won't allow me to update any of the settings for some reason, I just get an error.

Also for my .NET Web API application that I setup in AAD through the portal, i did not generate a client secret for the app, could this be part of my problem? And even if I did generate a client secret how would I use that in the .NET Web API application? because the way i have the code now in the startup.cs file is this:

        app.UseWindowsAzureActiveDirectoryBearerAuthentication(
            new WindowsAzureActiveDirectoryBearerAuthenticationOptions
            {
                TokenValidationParameters = new TokenValidationParameters
                {
                    ValidAudience = ConfigurationManager.AppSettings["Audience"]
                },
                Tenant = ConfigurationManager.AppSettings["Tenant"]
            });

there doesn't appear to be a use for a client secret, unless i'm totally missing something?

also would it be easier if I uploaded my code to github and posted the link for you to look at?

Thanks again for all the help! I truly appreciate it! I've tried looking around for examples of this but haven't found any and I feel like I'm just blindly poking around with this code :)

[davidhartman]

Waldek -

So I finally figured this one out. The first problem was that I had registered my client app in apps.dev.microsoft.com and this doesn't (from what I've tried) allow you to grant permissions to access another app in your tenant. So I needed to register both my apps in AAD inside the azure portal.

Also I was initially using hellojs instead of adal and adal-angular. Hellojs is great for interacting with applications registered at apps.dev.microsoft.com but adal and adal-angular works WAY better with apps registered in the azure portal.

After these changes everything worked! Hope this makes sense and helps someone in the future. Thanks again for all the guidance!

@waldekmastykarz