Getting a valid bearer token for an app from a an angular AD client

1
votes

I have followed this guide:

https://github.com/Azure-Samples/active-directory-angularjs-singlepageapp

and I connect successfully. I would like to send the bearer token to my C# server and use it to call my workbench(another AD app) functions.

I am trying to use the bearer token I get from angular in a postman call and it is unauthorized. It is important to mention that I gave my angular client on AD permission to access my workbench instance and it's still not working, that leads me to some questions:

I have tried using a .NET client from this guide:

http://blog.pomiager.com/post/using-rest-api-in-azure-workbench-blockchain

and it works. I notice here that in the AuthenticationContext object it receives credentials that is using the Client ID and the Client Secret. I notice that in the angular AD example we never use the secret. But the thing is that, when looking at the guide to create your own workbench UI, in the authService.js, it never takes the secret as a parameter as well. As can be seen here:

https://github.com/Azure-Samples/blockchain/blob/master/blockchain-development-kit/connect/web/workbench/custom-ux-sample/src/services/authService.js

I understand that that credentials should be set on the server. In the angular example that I provided there is also a ASP.NET server

How can I create a valid bearer token for the workbench from the angularJS AD example? Should I replace the OWIN lib with something else?

Thanks

1
azureazure-active-directoryazure-web-app-serviceadaladal.js

1 Answers

2
votes

You have two options:

  1. OPTION1 - Call Workbench API directly from AngularJS based SPA

    In this option you work with Implicit Grant Flow and only call Workbench API through Delegated Permissions i.e. in context of the signed in User.

    Also know that AngularJS SPA itself should not make use of any client secrets because it is a security risk and anyone using your application may be able to extract secret from JavaScript code.

    Here is a code sample from Azure Samples. This sample has TodoSPA (your AngularJS app) and ToGoAPI (separate API, analogous to WorkBench API). So you don't need to host the ToGoAPI yourself, but assume WorkBench API is your ToGoAPI. Follow the same steps just permission name 'Access To Go API' will be different and you will use Access Work Bench API instead.

    Call an Azure AD protected Web API in an AngularJS Single Page App

    enter image description here

    Important code pieces -

    In App\Scripts\app.js, replace the property name of the endpoints object to the new location of your To Go API, which will be Workbench api url in your case. In App\Scripts\toGoListSvc.js, replace the apiEndpoint variable with the same value.

  2. OPTION2 - Create a backend API that supports your AngularJS based SPA

    AngularJS SPA calls this backend server based API, which then calls Workbench API.

    In this option you can use client secrets and work with both Delegated permissions as well as Application Permissions.

    You need this option only if you need to work with Administrator permission shown in screenshot for Workbench API shown above.

    From a flow standpoint, you can directly use Client Credentials grant flow from backend API if you don't need to call Workbench with context of a user. In case you need to call in context of a user, make use of On behalf of flow.

Since your blog reference that you're trying to follow makes use of only Delegated permissions, I think you should be good with option 1 but you can decide further based on your requirements.