How to implement client API access to resources protected by Azure AD B2C

1
votes

I currently have an Angular SPA App that uses Azure B2c to authorise users, and use the token to pass to microservices to get/set all functionality.

I now want to build an API that clients can use to access the microservices themselves (either directly or through Azure API Management).

I cannot find any good documentation around this - but ideally I would want the users to be able to create "applications" in our App that would give them a API Key and Secret, and they could then use those to exchange for a JWT token that they can pass to the microservices - Azure B2C generated ideally so that it can just use the same authentication we are doing now. The API to convert the Key/Secret into the token would need to be non-interactive.

Azure AD B2C now supports ROPC but that doesn't seem suited, as that would just use the users username and password, which we don't want (as I want users to be able to revoke access). https://docs.microsoft.com/en-us/azure/active-directory-b2c/configure-ropc?tabs=applications

I could build this all external to Azure B2c - have own Identity provider that generates tokens for API, and on all microservices change pipeline to have two auth validations - one for Azure B2c Tokens, and one for own API identity validation, but was hoping there is a more streamlined approach.

Any suggestions?

1
azure-ad-b2c

1 Answers

2
votes

In this scenario you would architect as follows:

  1. User logs into your Portal. They use the Azure AD B2C policy to obtain their tokens.
  2. They use their Access Token to call your service
  3. Your service creates an Azure AD Application Registration in your Azure AD B2C directory
  4. It does this using Azure AD Graph API. Your API creates the App Reg, generates the required Application Secret and returns the AppId and Secret to the user
  5. You also need an App Registration to represent the micro service itself, and give the above App Reg permissions to it.
  6. Your microservice needs to trust 2 token issuers. The Azure AD token issuer and Azure AD B2C token issuer from the Azure AD B2C directory
  7. Now the user can use the client credential flow as per normal Azure AD, against your Azure AD B2C directory, and request the scope of your microservice App Reg.
  8. They then use the new token to call your microservice

If you use APIM or something similar, they can be configured to trust multiple token issuers.

In summary, the user authentication is protected by B2C User Flows/Policies, and the B2C token issuer. And the API based access is protected by the AAD endpoint of your B2C tenant. The microservice, since shared between both types of authentication mechanisms, needs to trust 2 token issuers.