I'm trying to set up account linking for a Google action which will use Authorization Code grant type to send a request to our internal OAuth infrastructure exposing /login and /token endpoints. According to account linking docs, the request will look something like:
GET https://myservice.example.com/auth?client_id=GOOGLE_CLIENT_ID&redirect_uri=REDIRECT_URI&state=STATE_STRING&scope=REQUESTED_SCOPES&response_type=code
We have similar infrastructure setup for similar kind of testing for Alexa skill, and the behavior between Alexa skills and Google actions seems to differ, so I have several questions related to those diffs:
In Alexa simulator, I'm able to see the generated request
with all relevant OAuth parameters (client_id, response_type, state, scope & redirect_uri) after clicking Save Permissions button during disabling/re-enabling skill flow:
- How can I enable a similar intercept of the generated request in Google Actions simulator?
I have configured a similar setup in Action's Account Linking tab:
however it doesn't seem to redirect to the /login endpoint of our OAuth server. I'd like to understand why that is the case, so in order to see which required parameters might be missing from the generated redirect to the /login endpoint, I need to be able to intercept/see it.
I'm suspecting the request is not being sent at all, because account linking is not working as expected, but I want to be able to prove it definitively for which I'd like to be able to intercept the request.
Is there a specific user action on Google simulator to trigger sending of that login request (akin to
Save Permissionsbutton in Alexa) or it must always be triggered from the webhook's code?Can we test account linking against our own OAuth provider without even having a Dialogflow webhook coded?
I'm assuming GOOGLE_CLIENT_ID, REDIRECT_URI, STATE_STRING, REQUESTED_SCOPES as documented per above don't have to necessarily be Google's and could instead be our own. Is that a correct assumption or does the client id always have to be Google's?