Get graphToken for local development

[fiyazbinhasan]

I followed the steps listed in local development section. However, I'm not sure how to get and store a graphToken for local development i.e. running on localhost throws 500. What would be the desired configuration for local.settings.json file for local development? TIA

[ConnorMcMahon]

Unfortunately our local development is still awkward due to a large dependence on App Service Authentication/Authorization, which can't be run locally yet. That means that you need to have an hosted Azure Web App (or Azure Functions Application) with EasyAuth already set up, and with various app settings set in your local.settings.json (in addition to the ones already documented in the readme).

UserFromId:

• WEBSITE_HOSTNAME - the host name of your application with EasyAuth enabled.
• WEBSITE_AUTH_SIGNING_KEY - matching the value of this application setting found in your application with EasyAuth enabled.

UserFromToken:

• WEBSITE_HOSTNAME - the host name of your application with EasyAuth enabled.

UserFromRequest:

• WEBSITE_HOSTNAME - the host name of your application with EasyAuth enabled.

To test any of these 3 authentication modes locally, sign in to your hosted application at the https://<hostname>/.auth/login/aad endpoint, and then make a GET request to https://<hostname>/.auth/me. If using UserFromToken, grab the id_token value from that response and putting it in UserToken field of the binding in the function's function.json. If using UserFromRequest, take the id_token field from the response and put it in the X-MS-TOKEN-AAD-ID-TOKEN header of an HTTP request. For UserFromId, grab the user_id field from the response and put it in the UserId field of the binding in the function's function.json.

ClientCredentials:

• WEBSITE_AUTH_OPENID_ISSUER-the base tenant URL for your AAD application.

The client credentials case shouldn't require setting any additional values for local development.

All of this should be more clearly documented in the README, though I want to take the time to test that this all works and to make the language more clear. Let me know if you encounter any issues with my instructions.

[SebastianSchuetze]

I made it work for my environment to get the graph token. I just give you my local.settings.json.
I used the ClientCrednetials method, which is for me the easiest one.

{
  "Values": {
    "WEBSITE_AUTH_CLIENT_ID": "**clientID**",
    "WEBSITE_AUTH_CLIENT_SECRET": "**clientSecret**",
    "WEBSITE_AUTH_OPENID_ISSUER": "https://sts.windows.net/**issuerId**"
  }
}

just be aware that the WEBSITE_AUTH_OPENID_ISSUER needs to be a url and not only the ID of the tenant in azure.

[fiyazbinhasan]

@ConnorMcMahon works like a charm! Used the UserFromRequest method. Although I think the WEBSITE_HOSTNAME is not required since it throws the following message on the console,

An item with the same key has already been added. Key: WEBSITE_HOSTNAME

Another thing, can you briefly explain the local usage of BYOB_TokenMap . Many thanks :)

[ConnorMcMahon]

@fiyazbinhasan, BYOB_TokenMap is the location that data about Graph webhook subscriptions is stored. Setting it to a local directory in your local.settings.json should be sufficient.

Speaking of Graph webhooks, unfortunately we don't have a good local development story for that yet. Creating a Graph webhook subscription requires the Graph API to hit an exposed endpoint of the Function runtime. Using a tool like ngrok may expose that endpoint properly to the Graph API, but that hasn't been tested yet, and there is likely some development work that would be required to make it work well locally.