skip to Main Content

I have the following scenario:

  • An organization has an internal application, X, which is registered under the ‘main’ tenant, allowing employees to utilize it.
  • App X has an API exposed for other applications (which are also registered under the main organization tenant) to used, and thus, this is all setup in AD.
  • A new B2C tenant has been created, where another public facing application, Y, will be registered.

How do I allow my App Registration for Y in my B2C tenant to use the exposed API of X?

Any feedback would be appreciated.

Edit 1:

I’m assuming I’d need to setup a Daemon auth flow, as the backend of Y will be authenticating with X as the app itself, and not as or on behalf of the user logged into Y.

Edit 2:

After some looking into this today, I’m considering creating an AD App Registration for Y in the main organization of X, allowing me to set up any connections that need to be made there, and I’d update the backend of Y to make a call as a Daemon to X, passing all the relevant information and client secret.

Seems a bit unusual, so will look for alternatives, but would also appreciate some feedback from someone who has more experience 🙂

Edit 3:

To clarify, I am looking to facilitate the communication between backend applications between two tenants, where one is a B2C tenant, and the other is an internal organization tenant.

2

Answers


  1. • Yes, you can surely allow the App registration considered Y in Azure AD B2C tenant to use the exposed API of another ‘App registration’ named X in an Azure AD tenant. For that purpose, you will have to configure the ‘Application Y’ registered in Azure AD B2C tenant as a ‘multitenant’ application and use it to start an authentication request to the authorization endpoint via a user flow. Thus, in here, the user flow defines and controls the user experience. After users complete the user flow, Azure AD B2C generates a token and then redirects users back to your application.

    For this purpose, you will have to configure a user flow in your Azure AD B2C application.

    Please refer to the below snapshots and steps defined for more details on this: –

    a) You might be having a front end and a back end to your application registered for authentication purposes with your web app. The backend application might have the authentication with the application registration X in an Azure AD tenant while the frontend application might have the authentication with the application registration Y registered in the Azure AD B2C tenant.

    Then, you will have to modify the front-end code for the web API and the back-end code for the web API as given in the below relevant link: –

    https://learn.microsoft.com/en-us/azure/app-service/tutorial-auth-aad?pivots=platform-windows#call-back-end-api-from-front-end

    For further configuring the authentication and authorization for the two apps, you can configure the front-end app to generate an access token that you can use to make authenticated calls to the back-end app. For this purpose, you will have to configure Azure AD as the identity provider with the app service configured for the front end as well as the back end as given in the link below: –

    https://learn.microsoft.com/en-us/azure/app-service/configure-authentication-provider-aad

    b) Once the above has been done, ensure that you are granting front end app access to the back end as below through the ‘Authentication’ section in the Azure AD app: –

    Then configure the app service to return a usable access token for the front-end app to access the back-end app with the required permissions for configuring the App service authentication and authorization on behalf of the ‘App registration Y’ in the Azure AD B2C tenant for it to access the ‘App registration X’ in Azure AD tenant as below by adding the scope parameter to the authentication setting ‘identityProviders.azureActiveDirectory.login.loginParameters’. Replace and in the below commands: –

     authSettings=$(az webapp auth show -g myAuthResourceGroup -n <front-end-app-name>)
     authSettings=$(echo "$authSettings" | jq '.properties' | jq '.identityProviders.azureActiveDirectory.login += {"loginParameters":["scope=openid profile email offline_access api://<back-end-client-id>/user_impersonation"]}')
    az webapp auth set --resource-group myAuthResourceGroup --name <front-end-app-name> --body "$authSettings"
    

    API permissions

    The commands effectively add a ‘loginParameters’ property with additional custom scopes. Here’s an explanation of the requested scopes: –

    openid, profile, and email are requested by App Service by default already.

    For information, see OpenID Connect Scopes: –

     api://<back-end-client-id>/user_impersonation is an exposed API in your back-end app registration. It's the scope that gives you a JWT token that includes the back-end app as a token audience.
    
     offline_access is included here for convenience (in case you want to refresh tokens)
    

    Thus, thereby you can call the back-end API (Azure AD app registration) from the front-end API (Azure AD B2C app registration) by injecting a X-MS-TOKEN-AAD-ACCESS-TOKEN header to each authenticated request as shown below: –

    https://learn.microsoft.com/en-us/azure/app-service/tutorial-auth-aad?pivots=platform-windows#call-api-securely-from-server-code

    Thus, in this way, you can surely expose an API for an application registered in Azure AD B2C for it to access the application in Azure AD.

    Login or Signup to reply.
  2. This can be achieved using multi-tenancy. Both the applications need to register as multi-tenant application.

    1.In Tenant A – Create an app registration as multi-tenant application in tenant A (eg: TenantA) and expose it as an API (api://app-id) and add the app roles in the application.

    2.In Tenant B – Create an app registration as multi-tenant application in tenant B and note the client-id of the application.

    3.The client id of application in Tenant B need to be added in known client application in the manifest of application registered in tenant A.
    enter image description here

    4.Provide consent to the application and permission in Tenant B to create the service principal using https://login.microsoftonline.com/common/adminconsent?client_id=clientIdOfTenantA&redirect_uri=redirectURIOfTenantA

    5.In Tenant B, service principal of Tenant A has been created under Enterprise applications

    6.Now tenant A is available in Tenant B. You can go ahead and make the API exposed in tenant A to the tenant B.

    enter image description here

    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search