2

I am working with Azure AD through OAuth 2.0 protocol and also creating a Service/ Dameon application to handle the authentication process for Microsoft Graph SDK. For the service/daemon, I make a HttpWebRequest and pass along the client_id and client_secret to generate an access_token where I then can supply to the Microsoft Graph SDK.

I also have successfully created a corresponding service principal to the target tenant, in which an admin has granted permissions to the application using the authorization code grant flow. The application then shows in Overview -> Quick tasks -> Find an enterprise app, within the (portal.azure.com).

My question is there an approach where I can leverage the service/daemon approach while also allowing an admin from the target tenant to authorize the application, that would allow the target tenant to create a client_secret to pass which would be unique to that tenant?

jdave
  • 845
  • 2
  • 11
  • 27

2 Answers2

4

Short answer is no. When an admin consents your multi-tenant app:

  1. A Service Principal is created for it in their tenant
  2. Permissions requested by the app are granted in that tenant

This means your app can now authenticate with its client credentials (id + secret) against their tenant as well. So the same keys work in all approved tenants.

What that means is your app is free to get an access token for any of them at any given time, no matter who is signed in. So it puts some responsibility to your app to keep data separated.

If you get an access token from https://login.microsoftonline.com/company.com/oauth2/token, the resulting token will contain that tenant's identifier. And APIs like the Microsoft Graph API will only give you data for that tenant with that token. So your app must make sure to only use a token that has a tenant id equal to the user's tenant id claim.

juunas
  • 54,244
  • 13
  • 113
  • 149
  • If that is the case, then what limits tenants from viewing other tenants users? – jdave Feb 10 '17 at 19:34
  • Edited my question. App permissions make it your app's responsibility to get a token for the intended tenant's data. If you use delegated permissions (which is not the case for a daemon), then it's less of a worry as you will always make calls as the user. – juunas Feb 10 '17 at 19:53
0

I would say that juunas' answer is 99% correct. The short answer is basically no, and the considerations he mentions are also solid.

But I believe that this would be technically possible under certain considerations. When the admin consents to your daemon service, a service principal is created in your customer's tenant. Service principals do allow addition of credentials that can be used as client secrets on a per-tenant basis. The thing is, there's not really a way to add a credential to a service principal programmatically from your app. You would have to get an administrator to run some script to add the new credential to their tenant's service principal.

Even if you went through all this, you would need to make sure that your service is also isolated on a customer/tenant basis. Security-wise, it's sort of pointless to create per-tenant client secrets if your singular daemon has access to all of the secrets.

dstrockis
  • 1,173
  • 5
  • 6