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

Question

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

AD Dev 126

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: https://learn.microsoft.com/en-us/graph/auth-v2-service .
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.

1 answer

Your answer

Answer 1

CarlZhao-MSFT 46,371

Hi, dear @AD Dev

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.

AD Dev 126 Reputation points

2021-11-01T21:14:35.883+00:00

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.
CarlZhao-MSFT 46,371 Reputation points

2021-11-02T03:15:23.913+00:00

Hi dear @AD Dev

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.
AD Dev 126 Reputation points

2021-11-02T15:58:19.227+00:00

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.
CarlZhao-MSFT 46,371 Reputation points

2021-11-03T01:48:31.263+00:00

This is definitely not possible. How can it access tenant A information only based on the application?
CarlZhao-MSFT 46,371 Reputation points

2021-11-03T01:54:26.373+00:00

To access any resource, an access token is necessary. Only you can obtain the access token, because only you know the client secret.
AD Dev 126 Reputation points

2021-11-03T15:25:34.79+00:00

Thanks, for taking the time to respond, that part is understood, I should have clarified: by "application" I mean't our service, not "app registration".

Consider a case where our service accesses the data for a user via the graph api. Only we would have the tokens, but we will use the graph api access data that the user would be able to see.

[User] -> [example-service.com] -> [graph api]

If we rely on the tenantId in the redirect callback of /adminconsent to know which tenantId maps to a given user, then in the case above, where user B changes the tenantId to user A's tenant Id, when user B uses our service, they would be able to see user A's data via our service since we have tied user B to user A's tenant within our service.

[User A] -> microsoft.com/common/adminconsent?state=abc -> [example-service.com]/redirect?state=abc&tenantId=tenantA -> [now we think that userA is tied to tenantA - good]

[User B] -> microsoft.com/common/adminconsent?state=xyz -> [example-service.com]/redirect?state=xyz&tenantId=tenantA -> [now we think that userB is tied to tenantA - bad]

then

[User B] -> [example-service.com/access-some-data] -> our service call graph api with tenantA credentials.

So basically, what we're interested in is a secure way to identify which user of our service, maps to a tenant they are an admin of, using client credentials flow with /adminconsent

Share via

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

1 answer

Your answer