dvdzo avatar image
0 Votes"
dvdzo asked dvdzo edited

In Graph api with Client credentials flow /adminconsent api - how to verify a particular tenant?

If we create a multi-tenant app registration, and want to access data for an external tenant via the client credentials flow we can ask their admin to consent using /adminconsent documented here: .
After the admin grants consent they are redirected to the redirect_uri, and the tenant_id is provided, however there is no way to guarantee that the tenant_id was not tampered with, furthermore, no way to know which of our users granted consent to a particular tenant. The question is, how can we know if a particular user of our application has access to a particular tenant if we are using the client credentials flow (or in other words, how can we tie one of our users to a particular tenant if they give us permission via client flow)?

I cannot think of a way for this to happen, only way I can think of to do this is to issue a second consent using the delegated oauth flow, and ask the admin to give us permission to call something like /organization or perhaps another api and read the tid embedded in the resulting access token for a successful delegated oauth grant, then we can know a particular of our application has admin privileges in a particular tenant.

Why not just use delegated flow? - in delegated flow the user, even an admin would have to take extra steps for our application to access the resources we need, but the client flow does not have this problem.

5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

1 Answer

CarlZhao-MSFT avatar image
1 Vote"
CarlZhao-MSFT answered dvdzo edited

Hi, dear @dvdzo

Your idea is a bit complicated, this is actually a very simple process. When you use the admin consent URL to log in to the administrator of the target tenant, it will still ask the administrator to consent to the MS graph permissions granted to the multi-tenant application in the original tenant. When the administrator of the target tenant consent, the multi-tenant application will be added to the target tenant as an enterprise application and have the permissions granted to it in the original tenant.


So I think you don't need to bind users to the target tenant for collaboration, because you are using the client credential flow and there is no user login involved. Next, you only need to use the client credential flow to obtain a token according to the normal process to access the resources of the target tenant.

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

340.png (83.0 KiB)
· 6
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

Thanks, the problem I have, is that I'm not sure how to know which user actually granted the consent because I don't have a way to know the tenantId of a particular user.

For example, with 2 users A -> tenantId1, B -> tenantId2. I present the /adminconsent link to A, and they grant consent. So now I can access tenantId1, but I don't know which user is part of tenant1. The redirectURI does provide the tenatnId, but it is not reliable because this is coming from the users's browser and they could just change it to another tenant. There is nothing stoping user B from saying he is part of tenantId1, unless there is some means that I can prove a particular user is part of a tenant, and this I'm not sure how to do, or if there is a best practice for solving this scenario.

0 Votes 0 ·

Hi dear @dvdzo

I don't think you need to worry about this at all. First of all, I think no tenant’s administrator will intercept your admin consent URL in the browser and tamper with the tenant id to add your multi-tenant application to his tenant, because doing so has no meaning, on the contrary, doing so is equivalent to authorizing your application can access the resources of his tenant, which will be a huge security risk. I believe no one will do this.

In addition, if user B is not the administrator of your target tenant and also consent to your multi-tenant application, how can he obtain an access token? Because he can't get the client secret of the application and can't get the token. Therefore, only your target tenant administrator consent to the multi-tenant application, and then you can obtain a token and access the target tenant's resources based on the target tenant's tenant id and client secret.

0 Votes 0 ·

In our use case, we can't have any vulnerabilities, regardless of if we think someone would exploit them or not.

Hypothetically, in the first case, an admin could create a dummy account that they don't care about being compromised for the purposes of attacking another.
In the 2nd case, if user B is not the admin of target tenant, yes they can't get the tokens, but they would still be able to use our application to access tenant A's information, which would not be acceptable.

0 Votes 0 ·
Show more comments