Skip to content
This repository has been archived by the owner on Nov 21, 2024. It is now read-only.

Obtain token using client credentials for different tenant than the one where function is deployed #105

Open
gotgenes opened this issue May 15, 2019 · 1 comment

Comments

@gotgenes
Copy link

gotgenes commented May 15, 2019

Our team is trying to use the Microsoft Graph auth token input binding for an Azure Functions application version 2 implemented in compiled C# on .NET Core 2.2. We want to use a "client credentials" binding, where the function can directly authenticate itself to AAD and interact with the Graph API. We do not want to use delegated permissions, where the function acts on behalf of a user authenticated with AAD.

Our function is deployed in a tenant (tenant ID 43e***) that is distinct from the tenant we want to query with the Graph API (tenant ID 849***).

The auth token binding seems to be affected by three application settings:

  • WEBSITE_AUTH_OPENID_ISSUER: the URL to the tenant from which to obtain an authentication token for the Graph API
  • WEBSITE_AUTH_CLIENT_ID: the client ID used by the function binding to identify the application to the tenant
  • WEBSITE_AUTH_CLIENT_SECRET: the client secret used by the function binding to authenticate to the tenant

We have found that all of these three settings appear to be populated strictly by Azure, itself, specifically for authenticating against the tenant in which the Azure function itself is deployed (43e***). We, however, want to authenticate to a tenant different than the one where the function is deployed, so that the token we get back can be used to query the target tenant (849***). Unfortunately we have found that none of these settings can be overridden in the Application Settings for the Function App.

Is there some other way to specify these pieces of information to the auth token binding so that we can get a token for a tenant that is different than the one on which we have deployed the function?

@tslavik
Copy link

tslavik commented Jul 30, 2019

Exactly what we need. I don't understand why it is not working cause we set up all attributes that are usually needed for getting a token.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants