I try to create actions for Google Home. For my new action I need to ask user authorization in my web site, I need to identified user. For this user should be find my action in Google Home app, linked on my web site and sign in.
My question in the next. Have I any chance to create all this using only emulator? Or without Google Home device I can't do anything?
You'll definitely be able to implement and test this just using the emulator, although it will not work as smoothly as if you had an actual device. The procedure is known as "account linking" and is detailed at https://developers.google.com/actions/develop/identity/oauth2-overview, but in general the flow is:
Your service needs to act as an OAuth 2.0 server and have an authorization page and a token exchange endpoint available to the Google Assistant.
When the user activates your Action for the first time, they're told they need to give Home permission to access your account and they should check the Google Home app for a card.
The card will redirect them to the authorization page, where they log into your website and authorize access to your site from Google Home.
As part of authorization, you'll continue the OAuth 2.0 flow and will (eventually) issue a bearer token that Google Home will store.
Users can then re-trigger the Action. Every time your webhook is called, Google Home will send this token to you.
You can then use this token to lookup which user is making the request.
There are a lot of additional details, which are covered in Google's documentation and in the OAuth 2.0 specification, but this is generally how it works.
For the emulator, users are not directed to the card in the Google Home app. Instead, you can see in the return JSON provided by the emulator the first time you activate the Action. In it, the debugInfo.sharedDebugInfo.debugInfo field contains the authentication URL. You should go to the URL in a browser, complete the sign-in and authorization flow, and will eventually be redirected to a URL that includes the parameter result_code=SUCCESS. After this, using the emulator will send the access token to your webhook. See https://developers.google.com/actions/tools/testing#testing_on_the_google_home_web_simulator for additional details.
Related
We have developed a Google Home Action integrating it with Keycloak OAuth and Custom Webhook The OAuth access token from Keycloak has a validity of 15 days
But after a long time of inactivity (1-2 months approx), the Testing Link was disabled and the Google Assistant was replying with the message '{Action Name} is unavailable right now' for all Smart Home Action voice commands like 'Sync my devices'
We have also enabled Testing in the deep link URL for the action test after this
But even after the Test was enabled, it still gave the same error message for all the voice commands.
What is the expected implementation change to be done either from the Webhook or Google Home Action configuration side to handle such cases as the Google Home App is not asking the user for relinking the Action if the access token gets expired in the backend?
The Keycloak URL and access details are configured in Google Action and the redirections to login and handling token are done by Google itself. So it is not in our control to get a new token without relinking the Google Home.
Relinking on Google Home is the only option here or should I increase the Keycloak token validity?
P.S. - Do not close this ticket if a satisfying answer is not received by me. My previous ticket was closed without a proper answer and I had to raise this question again.
The expectation is when an access token expires, Google sends a request to your token exchange endpoint to exchange a refresh token for a new access token.
Check out the Smart Home OAuth docs to make sure that you're endpoint is providing the exchange refresh token info to get access tokens. Below is an example of what your endpoint should return.
{
"token_type": "Bearer",
"access_token": "ACCESS_TOKEN",
"expires_in": SECONDS_TO_EXPIRATION
}
For more information on using tokens, I recommend checking out Google Account Linking, section "Working with tokens"
my code is based on this example
https://codelabs.developers.google.com/codelabs/smarthome-washer
The OAuth process is working. But now I want to know who is the user.
Here
https://developers.google.com/assistant/identity/google-sign-in-oauth?oauth=code
is described that:
After the user gives your Action consent to access their Google profile, Google sends a request that contains a signed assertion of the Google user's identity.
But if I test the authentication I never will be ask to give access to my Google profile.
I think that I have to configure which information my app wants to have from the user. But I didn't know where to do that.
I searched a lot but I couldn't find an example which really explains how to get the user information.
Thank you for your help.
Regards Simon
The OAuth process is working. But now I want to know who is the user.
Just a note here that the samples and codelabs use a fake OAuth implementation does not implement a user sign-in flow and returns a hard-coded fake access token during account linking.
Here
https://developers.google.com/assistant/identity/google-sign-in-oauth?oauth=code
is described that:
After the user gives your Action consent to access their Google profile, Google sends a request that contains a signed assertion of the Google user's identity.
Smart home actions do not support the Google Sign-In account linking flows. You need to implement the OAuth authorization code flow in your account linking integration.
I think that I have to configure which information my app wants to have from the user. But I didn't know where to do that.
I searched a lot but I couldn't find an example which really explains how to get the user information.
This is essentially the opposite of what account linking accomplishes. The goal is not to provide user information from Google to your Action. Instead, account linking is used to authorize Google to access your user's devices by providing Google with an access token that your service considers valid for a particular user within your cloud service.
So in this case, you are the one that owns the user data. You are simply providing Google scoped access to that data for sending queries and commands to devices.
The Facebook Platform Policies section 1.6 clearly states
Your website must offer an explicit "Log Out" option that also logs the user out of Facebook.
The Login Flow for Web without Javascript SDK says on Logging people out
You can log people out of your app by undoing whatever login status indicator you added, for example deleting the session that indicates a person is logged in. You should also remove the stored access token.
On the other hand the Login Flow for Web says about Logging people out
Note: This function call will also log the person out of Facebook. The reason for this is that someone may have logged into your app and into Facebook during the login flow. If this is the case, they might not expect to still be logged into Facebook when they log out of your app. To avoid confusing people and to protect personal security, we enforce this logout behavior.
So in my understanding the Login Flow with JS SDK does what the policy says, it logs the user out of Facebook as well. How do I implement the Login Flow without JS JSDK correctly, such that i do not violate the Facebook Platform Policy? So far i don't see that the Graph API offers a similar functionality.
That should be easy, looking at the PHP SDK’s method getLogoutUrl, that creates an URL of the following scheme:
https://www.facebook.com/logout.php?next=FOO&access_token=USER_ACCESS_TOKEN
For FOO you just place the URL of your website where you want the user to be redirected to after they are successfully logged out of Facebook (don’t forget to properly URL-encode that value), and USER_ACCESS_TOKEN should be self-explanatory. (You need an active user access token to log the user out of Facebook – obviously, because otherwise every site on the web could just redirect me to this address and log me out of Facebook, without me actually wanting that to happen.)
I've got the Live Stream box plugin working on my site using the code output from the developer documentation. What I want to do is when a user clicks login it asks for authorisation to use the app with the permissions e.g. email address, that I've requested in the auth part of the app. Is this possible?
use the scope parameter
see http://developers.facebook.com/docs/reference/api/permissions/
I'm curious how these systems work technologically. As I understand it you do the following as a user:
Go to your favorite 3rd party site.
Click the "Facebook Connect" button.
Log into Facebook (if not already).
Authorize Application
You are routed back to the 3rd party site logged in.
But, how does the 3rd party site talk to FB about who you are? I can understand how it could get the information it needs when you initially authorize the application, but how would it know afterwards? Here's a scenario:
You go to Facebook and log in.
You then go to your favorite 3rd party site (which you already authorized).
It already knows you are logged in!
A background ping using an IFrame is performed, and if the currently signed in account has already authorized the application, then the access token and user id are returned to the application. With this the application can decide what to do (usually, set a cookie and refresh the page so that the server can re-render the page knowing who you are based on the cookie that was just set). If you're curious, you can look at the Facebook implementation of the client side JS method called FB.getLoginStatus() here: http://github.com/facebook/connect-js/blob/master/src/core/auth.js#L117
It's using a 3-legged authentication system called OAuth.
After you start the process, the 3rd party site connects to Facebook, and if you were already logged into Facebook (live session with cookies) then it will just use that, and ask permission to authorize the 3rd party app.
Once it is authorized, it will get an auth_token, which it can use to access information from your account, unless you revoke it's access.
Check out OpenID. Also this presentation is very interresting: Facebook Connect vs FriendConnect
It all happens through OAuth2 mechanism ,where the third party application already registers with the facebook(or any other website which has oAuth2 implementation) and gets the Id(usually termed as clientId) and secretCode(i.e., clientSecret).
So, when you want to login into the third part app through fb, the service provides (clientId+clientSecret+callbackUrl )---> to facebook.while , the first two were to authorize the third part service and callback URl is URL where facebook responds back with a "accessToken" for that account.
Using this accessToken , the third part service will invoke facebook's graph api's to get the user related info and use them to login the user into their service.