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
Related
I have an already deployed application on azure app service which uses azure AD for authentication and authorization.
Unfortunately the developer who worked on it is no longer available
i got access to all Azure resources and source code but i cant figure out how can i add my azure account as one of the users to the app (i can login but its an empty view for me unlike what it used to be with the developer access).
Also i find the app registered on Azure AD and i am an owner there but still with no right access.
When i try to login localy from the frontend it say
Selected user account does not exist in tenant 'Default Directory' and
cannot access the application '[some numbers] in that tenant. The
account needs to be added as an external user in the tenant first. Please use a
different account.
Would appreciate any help and many thanks in advance.
I can login but it’s an empty view for me unlike what it used to be
with the developer access
This is because your backend application is enabled with Azure AD Authentication.
After you sign in to your front-end application, you still can't access the data from the back-end app, because the back-end app now requires Azure Active Directory sign-in from the front-end app
To access the application, follow the below steps:
Grant the front-end access to the back end
Configure App Service to return a usable token
Use the token in your code
You can refer Enable authentication and authorization for front-end app in Authenticate users E2E - Azure App Service | Microsoft Docs for the detailed steps
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
I've done some reading in regards to Azure AD, but I still can't wrap my head around it. The confusion might be there also because of how my company tries to standarize how a azure project should look like.
Imagine I have two things: SPA app (served by App Service) and API (on this App Service, ASP.NET). The approach that the company is suggesting is that both of those should have their App Registrations.
Now, I'd like the API to have access to Ms Graph. In order to do that, looking at other projects, I updated my AppRegistration to request for Ms Graph roles, Admin gave consent, and in API I used ConfidentialClient to reuse my Client Id/Secret to get token and then access MsGraph.
Why the hustle? Why not just use Managed Identity of my API and grant needed permissions using New-AzureAdServiceAppRoleAssignment?
Why do I need App Registration here? Do I need both? Should I access Ms Graph using my App Registration and confidential client in my API? How does my App Service relate to my App Registration in code?
Let's take a step back and define a few things that will make things easy to understand:
Your app service: this is just a compute environment, just as Azure Functions, Logic apps or VMs. This is where your code executes.
Azure AD App registration: this is an identity that you can use in your code to identify your service and get access to resources you need. The Azure AD app registration has several capabilities:
build an app in one tenant and used in multiple tenants (multi-tenant app)
consent framework, allowing you to request permissions and the owner to grant it
define roles and permissions, so that you can configure who is allowed to call your API
3-legged OAuth flows which allows you to act on behalf of the user
confidential client flows which allow the app to act on its own (like a service account)
Azure Managed Identities: this is also an identity that you can use to identify your service and get access to resources you need. It only has a subset of the capabilities of Azure AD app.
confidential client flow which allows the identity to act on its own (like a service account)
credentials managed for you by the platform
Depending on what you are trying to do, you can use one or the other identity: rarely if ever you will need both.
In your case, you need an identity to act on its own. So either app registration or managed identity will work. Your API may benefit from using an app registration if you want to define roles and permissions. The primary advantage of using an app registration in your scenario is that the consent model is simpler to use and understand. The disadvantage is that you need to manage credentials for the app. This pro/con is reversed when using a managed identity.
You don’t need both at a time. These are two ways to get the access of MS graph for your API. They are used for different purpose.
Managed Identity (Using System Identity)
· Use the Managed Identity if you don’t require your API to be authenticate from any provider.
· A managed identity from Azure Active Directory allows App Service to access resources through role-based access control (RBAC), without requiring app credentials
· It known as safe way to give your web app access to data is to use a system-assigned managed identity
· Currently, there's no option to assign any permissions(MS graph) through the Azure portal for Managed Identity
· When we do Manged Identity of any application its show only for Enterprise application.
Reference : Tutorial - Web app accesses Microsoft Graph as the app - Azure App Service | Microsoft Docs
App Registration.
· To set the authentication and authorization of your app from different provider its need your app registration id.
· It’s required to configure a service and get a token from the Microsoft identity platform endpoint that service can use to call Microsoft Graph under its own identity.
·In this using portal you can add permission (MS Graph) for your application.
Reference : https://learn.microsoft.com/en-us/graph/auth-v2-service
I have a client application which runs as daemon mode [no interfaces].
This daemon will speak to app created in Azure (single-tenant currently) to fetch users using O365 Graph API.
Authentication mechanism used is Auth2 certificate/thumbprint.
Permission to app is given directly by admin while creating app in azure itself.
Now i need to make this daemon (client) and app in azure as multi tenant.
Things i followed after reading some articles
Mark app as multi-tenant in azure
Point to /common in token url in client (which runs as daemon) https://login.microsoftonline.com/common/oauth2/token.
Questions:
After this i was able to get access token , but for any query i make i am getting error "The identity of the calling application could not be established".
Since there is no user intervention here , how do i give permission for tenant B app to access tenant A's data like users in my case ? Anything i can do in manifest file
If tenant B's app is accessing tenant's A data , should both app in azure be mutlitenant ?
Lot of articles explains how is the flow based on user login (user consent). But my client application runs as daemon. How do i give permission directly/mechanism in azure app for accessing other tenant's data ?
[Assume i am admin of both tenants and i have complete access to both tenant]
It isn't possible to use the common endpoint when using the client_credentials flow to log into the \OAuth2\token endpoint. This is because common is designed to identify the user's "home" directory and when they log in interactively they are redirected to sign into their home directory unless overwritten.
2 & 3. Tenant B doesn't get a registered application it only get an Enterprise Application. The linked Registered App would be the one is Tenant A, communication here isn't bi-directional. A has an Enterprise Application in A and an Enterprise Application in B. You set the permissions for all the Enterprise Applications using the Registered Application in A but an Admin/User -dependant on the permission type- will have to grant permissions in their respective tenant (A & B). When you log in as a user you utilise the Application Registration. In order to access B you will have to call the token endpoint containing B's tenant id.
To enable one application to be able to access multiple tenants you need to:
make the Application Multi-Tenanted. Make a note of the application's ApplicationId.
Using PowerShell log into the tenant you want to give the Application access to.
Use the Cmdlet New-AzureRmServicePrincipal -ApplicationId <ApplicationId> where is the one you noted earlier.
This will create a service principal in tenant B based on the application in Tenant A. The application in A when then be able to use the token endpoint for Tenant B to log in an access.
We have an Azure resource app whose APIs we want to expose for access by a client app on Azure. The two apps are on different tenants. The users accessing the APIs (Office 365 account holders) are on different tenants.
The whole set up works when we manually provision a service principal on the tenant that is trying to authenticate from the client app against the resource app. By that I mean they are able to log in using their Office 365 account and are shown the consent screen.
If we do not provision a service principal on the AAD tenant of the user trying to authenticate, we get this error:
AADSTS65005 - The app needs access to a service <service> that your
organization org.onmicrosoft.com has not subscribed to or enabled. Contact
your IT Admin to review the configuration of your service subscriptions.
It is not feasible for us to provision a service principal on every tenant that is accessing our app (resource app). Is there something we are missing? Are we using the right flow?
You can find help for your scenario here: https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-devhowto-multi-tenant-overview#understanding-user-and-admin-consent. (Scroll down to Multiple tiers in multiple tenants)
In the case of an API built by an
organization other than Microsoft, the developer of the API needs to
provide a way for their customers to consent the application into
their customers' tenants.
The recommended design is for the 3rd party
developer to build the API such that it can also function as a web
client to implement sign-up:
Follow the earlier sections to ensure
the API implements the multi-tenant application registration/code
requirements
In addition to exposing the API's scopes/roles, ensure
the registration includes the "Sign in and read user profile" Azure AD
permission (provided by default)
Implement a sign-in/sign-up page in
the web client, following the admin consent guidance discussed earlier
Once the user consents to the application, the service principal and
consent delegation links are created in their tenant, and the native
application can get tokens for the API
Basically, all of the parts that your app needs must be present as service principals in the customer's tenant. This is a requirement of AAD.
The only way for that to happen is for an admin to go through consent for the API and app separately, since they are registered in different tenants.
If they were registered in the same tenant, you could use the knownClientApplications property in the manifest to allow consenting to both at the same time.
In my case, I am exposing my own API and trying to access this API from my other Application (Client Credentials mode), I removed the default permission on both of the app(consuming app and api app) - "Azure Active Directory Graph-> User. Read" since I thought I don't need that but that caused this problem "The app needs access to a service .... that your organization has not subscribed to or enabled. Contact your IT Admin to review the configuration of your service+subscriptions.
I got the clue from the answer of #juunas - point 2. Thx Juunas