I have an Azure service using Azure Active Directory for authentication/authorization. I am trying to set up a google action fulfillment (using a webhook) to access this service for information regarding the user. Trying to use Account Linking for this.
The issue is I am not receiving an access token in my service when the action fulfillment makes the call via the webhook. It is supposed to be in the request body inside the User object. So I'm always getting a 401 response.
It seems the fulfillment expects to authenticate itself using the signed in google user's account via OAuth (correct me if I'm wrong). However, I'd like my service to authenticate each fulfillment request using a single Azure AD account, and not each individual google user account. My Azure AD has no knowledge of google users.
How would I achieve this? I have configured Account Linking to use OAuth using my service's secret and appId, etc. The setup is correct on the Azure side, since I can retrieve a valid token using Postman for eg.
It sounds like there are two different types of authentication you are trying to do here:
You want to make sure that the call to your webhook is coming from Actions on Google.
You want to know who the user is that is calling your Action.
As you noted, (2) is handled by including the auth token as part of the body of the request. You are expected to authenticate that once your webhook is called, which is why it is not provided as part of the Authentication header. This is what the Assistant does when it does Account Linking - if you don't need to do this, you don't need Account Linking enabled for your Action.
(1) is handled differently depending how you have built your Action. If you are using the Action SDK, then a JWT Token will be sent in the header which you should verify as being for your project and signed by Google. If you are using Dialogflow, you can configure the fulfillment to send headers or basic authentication which you can verify on your webhook.
Neither the Action SDK nor Dialogflow support OAuth 2.0 / OpenID Connect headers when calling the fulfillment server (I don't know why for sure, but my speculation is that it adds a great deal of complexity for very minimal security benefit). If you can't support either of these schemes when you're dealing with (1), then you will need to setup a proxy that can do something like: