I have a service registered as a multi-tenanted Web API in an AAD tenant “A”. And a client registered as a web app in a different AAD tenant “B”. The question is, whether do I need any additional configuration on Azure portal in order for the client app in tenant “B” to successfully access the web API in the tenant “A” (app to app authentication) ? Does AAD support such scenario? Currently, I get Unauthorized status code as response from the service when the service is deployed to Azure.
The service in tenant A doesn’t show up when I try to manually manage permissions for the client app in tenant B. Is this step necessary or am I missing some config set up?
The service is built on asp.net MVC application and it uses JWT bearer authentication scheme. The client successfully acquires its token from its own AAD tenant. So it doesn't seem like an authentication issue. On the service side, I have added the client's tenant to be one of the valid token issuers as well.
I'm not sure if a service principal for the service app is created in the client's tenant automatically (the consent page has never showed up so far).
The scenario is supported.
You'll just have to consent to the API from tenant B first before it shows up in the list.
You can define your application permissions on the Web API as normal (check here).
Then you can go through consent for the API by accessing a URL like this:
https://login.microsoftonline.com/tenant-b-id/oauth2/authorize?client_id=your-api-client-id&response_type=code&redirect_uri=reply-url-defined-on-api&prompt=admin_consent
You'll have to replace 3 values there with yours:
tenant-b-id: the directory id for tenant B
your-api-client-id: The application id/client id of your API in tenant A
reply-url-defined-on-api: URL-encoded reply URL defined on your API in tenant A (e.g. https%3A%2F%2Flocalhost%2F)
That should then result in a service principal getting created in tenant B for the API, allowing you to assign app permissions to apps in tenant B.
Related
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.
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.
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.
• 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"
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.
I've been poking around MS Graph OAuth2 consent and access token for the enterprise Azure app that had been created along the way. Basically, I'm confused why when I delete the app, I'm still able to obtain the access token ?
When I decrypt and check the claims, it is referencing the name and object id of the deleted app, but it has no roles, and can't be used to access any resources, which makes sense. But still, I'm confused why is being issued for the app that doesn't exist any more ? For example, if I open the app and select to disable login for users, access token is no longer issued - but deleting the whole app does not behave in the same way.
While working with applications in Azure AD, you should be aware of few things like:
App Registrations is where you register an application and configure the details like API permissions, client secrets, client certificates, token claims, app roles etc....
Enterprise Applications are list of service principals that are associated with applications in App Registrations which defines who and what resources the application can access.
When an app is registered in Azure AD, it's corresponding service principal will be created with same name and same App ID in Enterprise Applications blade automatically.
Please note that, whatever changes you do to service principal will directly affect the registered application and vice versa.
I tried to reproduce the same in my environment and got the below results:
I have registered an application in Azure AD and granted permissions like this:
Go to Azure Active Directory -> App Registrations -> Your App -> API Permissions
I generated an access token using client credentials flow, and I can see the roles claim in decoded token like below:
Now, I deleted the Enterprise Application of same name and App ID like below:
Go to Azure Active Directory -> Enterprise Applications -> Your Application -> Properties -> Delete
After deleting that Enterprise App, I'm still able to generate the access token and can't find roles claim now like below:
As the service principal of the application is deleted, you cannot access the other resources which removes permissions from token.
Please note that,
If you delete the application in App Registration first instead of Enterprise App, it will automatically delete the associated service principal (Enterprise App) too along with it.
Then you cannot even generate the access token as it gives Unauthorized client - Application not found error. Unable to generate access tokens is similar to disabling login for users.
Reference:
Apps & service principals in Azure AD | Microsoft Docs
I have a multi-tenant app registered in my Azure tenancy (TENANT A). I am trying to get the groups and group members of tenants that have logged into the app. I have the following permissions set up under App Registrations in TENANT A.
When I signed into the app as an admin user from TENANT B, I had to grant consent for the permissions and login worked as expected.
I want to be able to see all groups/members of TENANT B. I am not sure how to do this. I have tried following the explanations here but am having no luck. I am performing a post to https://login.microsoftonline.com/*TENANT B*/oauth2/v2.0/token and getting a response
However, when I use the response token and call the Graph API https://graph.microsoft.com/v1.0/groups/*GROUP OBJECT ID*/members it says that I have insufficient permissions.
Any help would be much appreciated
You created a multi-tenant application in tenant A for generating access token and call graph api to get all the groups. When you created the app and it's consented to the api permissions, it would work for tenant A, but not for tenant B as this app hasn't registered in tenant B and got the consent. You may refer to this section
and grant tenant-wide admin consent by hitting the url below. Then you may check if this app appeared in the azure portal -> azure ad -> enterprise applications in tenant B and click the app -> permissions to see if it has consent.
https://login.microsoftonline.com/{tenant_id_of_tenant_B}/adminconsent?client_id={app_client-id_in_tenant_A}
By default, web app/API registrations in Azure AD are single-tenant. You can make your registration multi-tenant by finding the Supported account types switch on the Authentication pane of your application registration in the Azure portal and setting it to Accounts in any organizational directory. (see pic below)
Before an application can be made multi-tenant, Azure AD requires the App ID URI of the application to be globally unique. The App ID URI is one of the ways an application is identified in protocol messages. For a single-tenant application, it is sufficient for the App ID URI to be unique within that tenant. For a multi-tenant application, it must be globally unique so Azure AD can find the application across all tenants. Global uniqueness is enforced by requiring the App ID URI to have a host name that matches a verified domain of the Azure AD tenant.
https://learn.microsoft.com/en-us/azure/active-directory/develop/howto-convert-app-to-be-multi-tenant#update-registration-to-be-multi-tenant
Is it possible to secure a Web API in an App Service within Azure, using the built in Authentication/Authorization options and at the same time access it using the OAuth Client Credential Grant flow?
I have an app service being authenticated with Azure AD B2C. In that B2C tenant I have the web app/API registered and authentication working fine for using the web app.
I added a scope in the Published Scopes section of that AD B2C app and also added an App ID URI for that scope.
Then I created another App (ClientApp) in the tenant to represent another service I want to provide access to the first API. I generated a Secret key for it and also in the API access section added the scope I had created in the other app.
Then in postman I get the token using the next
Grant type: Client credentials
Access token URL: https://login.microsoftonline.com/mytenantname.onmicrosoft.com/oauth2/v2.0/token (for some reason I have to use login.microsoftonline as the b2clogin domain doesn't work for this)
Client ID: The ID that appears in the app registered for the ClientApp
Client secret: The secret generated under the ClientApp
Scope: the App ID URI I added the the web app registration.
I successfully get the token, but when I try to access the web site using the bearer token with postman, I just get a 401.
It is not supported to use client_credentials flow against AAD B2C application registrations. Therefore you have to instead create an App Registration through the normal Azure AD Blade instead.
https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-apps#current-limitations
Then the App Service must accept tokens from 2 different authorities, which App Services cannot do with EasyAuth (Authentication enabled at the App Service configuration menu).
You would instead need to use a library that can accept tokens from multiple authorities. There is an example here:
Use multiple JWT Bearer Authentication
I've spent hours to find a proper solution.
This solution: https://stackoverflow.com/a/48657826/11721142 doesn't work with mine B2C setup (is almost ideal :) ). I had to change original:
"additionalLoginParams": [
"response_type=code id_token",
"resource=<AAD-app-id-for-your-webapi-webapp>"
]
To:
"additionalLoginParams": [
"scope="scope=https://xxx.onmicrosoft.com/{Guid}/all+openid+offline_access""
]
Where
https://xxx.onmicrosoft.com/{Guid}/all is your scope identifier defined in B2C API permisions
Then... finally I can call {frontend-app-domain}/.auth/login/aad and... see: access-token, id-token and refresh-token after {frontend-app-domain}/.auth/me
You can also provide required scopes like that: {frontend-app-domain}/.auth/login/aad?scope=<see scopes above>
Not sure if I understand it correctly, but it seems you are using a URL as scope. It works if you set the scope to the application id of the app service (you can find an enterprise application with the name of your app service in azure AD) instead of using the URL. (format: /.default)
I am still trying to figure out if it is possible to use the URL as scope...
There is a Client in Tenant A. There is a Resource Server (Web API) in Tenant B. I'm developing both Client and Web API. I'm admin in both Tenant A and B. OAuth 2.0 grant type is Client Credentials so no End-Useris involved. My Web API (AAD App) exposes AppRoles which I described in Web API (AAD App) manifest (I named one of them client_access). For both AAD Apps(Client and Web API) I turned on multi-tenant option. And they have globally unique App ID URIs.
Now Client (AAD App) wants to request permissions to access Web APIin this role (client_access). Because they are in different tenants I created a Service Principal representing the Client in Tenant B. Now I want that Admin of Tenant B would provide this Service Principal with permissions/consent on requested role client_access providing by Web API.
But how (being an Admin of a Tenant) using Azure Portalcan I find this Service Principal? App registration page shows only AAD Appsbut not Service Principals. I don't see ClientAAD Appeither (in App registration page in Tenant B).
With single tenant situation everything is easy -- I select Client, go to Required permission section, push Add button, find there my Web APIand check client_access checkbox, then I push button Grant Permissions to provide my consent.
Anyone have a clue on How to provide permissions for Client to access Web API in multi-tenant scenario using Azure Portal or PowerShell or other means?
Maybe my overall approach is wrong? So advice please.
P.S.
We will publish/expose this Web APIto many of our partners so they will be able to develop their own Clients (residing in their tenants). They will requests access and I will grant/consent/approve their requests to my Web API. And after permission is established the Clients will communicate with Web APIusing OAuth 2.0 Client Credentials grant type with an access token.
Thank you