Google Home授权代码和Google帐户身份验证 [英] Google Home Authorization Code and Authentication with Google Account

问题描述

我目前正在尝试使用Google Home Action对Google帐户进行身份验证，并从凭据中检索授权代码。我不要访问令牌，但授权码。

我看过

• 您有某种类型的数据存储，您将在其中存储用户的Auth令牌和Refresh令牌。我假设您使用Google的用户ID作为此数据存储的索引。

  
  
  
  
  

  • 通过 Google在这种情况下，用户ID是指Google分配给每个帐户的唯一数字标识符。尽管它只有数字，但通常用字符串表示，因为它通常比大多数数字类型长得多。在ID令牌中，这是子声明。

  
  

  • 理论上，您可以使用ID令牌中的声明中可用的其他标识符，例如他们的电子邮件地址。不幸的是，并非所有这些字段都保证可用-只能保证 sub。

  
  



• 您有一台Web服务器，其中将包含一些对我们有用的重要URL：

  
  
  
  
  
  • 用于实现操作的Webhook。
  
  
  • 登录/身份验证页面。
  
  
  • 登录页面上的javascript将向您发送身份验证代码的端点。
  
  



• Google助手，该助手可能在Google Home或移动设备上运行。我们还假设用户将能够使用浏览器查看其授权内容。




• 您将使用的Google服务，包括Google的OAuth服务

让我们从用户先前登录并授权我们访问其服务的情况开始代表。我们在数据存储区中拥有他们的Auth令牌和Refresh令牌，并根据其Google用户ID进行了索引。这是简单的情况，但是它可以帮助我们理解所有数据如何进入其中的更复杂的情况。

数据流看起来像这样：

1. 助手发送操作使用webhook一个Intent和可能的参数。如果这是第一条消息，则表示欢迎，但这没关系。它包含一个身份令牌，我们将需要对其进行解码和验证。作为解码时得到的数据的一部分，它包括用户的用户ID。


2. 使用用户ID…


3. 。 。


4. 有了Auth Token和Refresh Token，我们可以代表用户对Google的服务进行一些操作。


5. 我们将从服务中获得一些结果……


6. ...我们通常希望以某种形式将其传递回用户。

容易，对吧？但是，如果用户之前从未使用过助手与我们的操作进行交谈该怎么办？而且从未授权我们访问他们的Google服务，所以我们没有他们的令牌吗？该流程看起来像这样：

1. 助手向动作Webhook发送一个Intent和可能的参数。这将是第一个消息，因此我们的欢迎意向被触发。没有身份令牌。


2. 网络挂钩显示没有身份令牌，因此我们发回一条消息，说他们需要访问我们的网站才能授权我们访问其Google服务。我们可能会要求他们切换到移动设备来执行此部分，甚至包括指向登录页面的链接。 （这是上面的折叠的步骤2和6。）


3. 他们将在带有屏幕的设备上跟踪链接。


4. 我们'将发回登录页面，其中包含指向使用Google登录的链接。我们已经配置了此按钮，以询问我们访问其服务所需的其他范围，以及在脱机时代表他们访问服务的权限。


5. 它们将进入通过Google登录舞蹈，进入OAuth范围屏幕，并有望授予我们所需的所有权限。 （同样，如果他们不这样做，我会忽略发生的事情。）由于与我们无关，我忽略了这种舞蹈的样子。假设一切顺利，Google会为他们提供一个Auth代码，登录页面上的javascript发送给我们。


6. 我们称Google的OAuth服务器验证Auth Code并使用它来获取Auth Token和Refresh Token…


7. …然后将其存储在数据存储中…


8. …然后发回一些东西，以便Javascript页面可以告诉用户他们从现在开始就可以正常使用我们的操作。

还值得注意的是，他们甚至在访问网站之前尝试使用Assistant版本（即-由于搜索结果，或者他们从第二个图表中的第8步或从第三个图表中的第4步开始），然后登录，那么我们将获得他们的身份令牌 first >他们通过助手访问我们的时间，这就像简单的情况一样。

I am currently attempting to authenticate a Google account with a Google Home Action and retrieve the Authorization Code from the credentials. I do not want the access token, but the authorization code.

I have looked at this post and discovered that Google has updated their policy and no longer allow their own OAuth endpoints to be used for the account linking authorization code flow:

When implementing account linking using OAuth, you must own your OAuth endpoint

That being said,

1. What is the correct way to authenticate an existing Google user with my Action and the necessary scopes? (I need calendar access)
2. Is it possible to do this authentication without having to create my own OAuth2.0 endpoints?
3. And from this flow, is it possible to extract the authorization code?

解决方案

The current way to authenticate a user through their Google account is to use Google Sign-In for Assistant. Once they log in to your Action, you'll get an id token which you can decode to get their Google ID, which you can use to look up their account in your datastore to get their access/refresh tokens.

Since you need additional scopes, if the user logs in to the Assistant and does not already have the scopes attached to their account, you'll redirect them to a web-based login page where they can log in using Google Sign-In with the scopes you need. In this case, when they log in and authorize access through the web, you will get the auth code which you will need to exchange for the auth token and refresh token and store these.

You do not need to create your own OAuth endpoints for this, although you will need to do a bit of additional work to make sure they get redirected to your website to do the authorization if necessary.

You will only get the auth code once when they log in and authorize you. You will need to exchange this for the auth and refresh tokens and then store these tokens.

Update to explain things a little better.

Looking at the architecture, we see it has a few components. We’ll go into the details of each of these as we go through the process flow:

• You have a data store of some sort, where you will store the Auth Token and Refresh Token for the user. I’m going to assume that you’re using Google’s User ID as the index for this data store.

  • By "Google User ID" in this case, I mean the unique numeric identifier that Google assigns to each account. This is often represented as a string, despite having just numeric digits, since it is usually much longer than most numeric types. In the ID Token, this is the "sub" claim.

  • In theory, you could use other identifiers that are available from the claims in the ID Token, such as their email address. Unfortunately, not all of these fields are guaranteed to be available - only the "sub" is guaranteed.

• You have a web server that will have a few important URLs for our purposes:

  • The webhook for your Action fulfillment.
  • A login/auth page.
  • An endpoint where the javascript on the login page will send you the Auth Code.

• The Google Assistant, which may be running on a Google Home or on a mobile device. We also assume that the user will be able to get to a browser to review what they are authorizing.

• The Google services that you will be using, including Google’s OAuth service

Let’s start with the case where the user has previously logged in and authorized us to access the service on their behalf. We have their Auth Token and Refresh Token in our data store, indexed against their Google User ID. This is the simple case, but it helps us understand the more complicated case of how all that data gets in there.

The data flow looks something like this:

1. The Assistant sends the Action webhook an Intent and possible parameters with it. If this is the first message, it is a welcome intent, but it doesn’t matter. It includes an Identity Token, which we will need to decode and verify. As part of the data we get when we decode it, it includes the User ID for the user.
2. Using the User ID…
3. ...we get the Auth Token and Refresh Token from the data store.
4. With the Auth Token and Refresh Token, we can carry out some action against Google’s services, acting on behalf of the user.
5. We’ll get some results back from the service…
6. ...which we usually want to pass back to the user in some form.

Easy, right? But what if the user has never used the Assistant to talk to our Action before? And has never authorized us to access their Google services, so we don’t have their tokens? That flow looks more like this:

1. The Assistant sends the Action webhook an Intent and possible parameters. This will be the first message, so our welcome intent is triggered. There is no Identity Token.
2. The webhook sees there is no Identity Token, so it sends back a message requesting the "Sign In" helper function. Since your project is configured to use Google Sign-In, the Assistant will prompt the user if they can give you their profile information.
3. If they say yes, you’ll get another response saying they have signed in and including the Identity Token, which we decode and verify and get their User ID. (If they say no, we’ll get a response saying it failed. How you handle this is another story. I’m going to assume they say yes.)
4. Using the User ID…
5. ...we try to get the Auth Token and Refresh Token from the data store. But they haven’t authorized us yet. We have authenticated them, but don’t have authorization...
6. ...so we send back a message saying they need to visit our website to authorize us to access their Google services. We may require them to switch to a mobile device to do this part and even include a link to the login page.
7. They will follow the link on a device that has a screen.
8. We’ll send back the login page, which includes a link to Login with Google. We’ve configured this button to also ask for the additional scopes we need to access their services, as well as permission to access the services on their behalf when "offline".
9. They will go through the Google Login dance, the OAuth scopes screen, and will hopefully grant all the permissions we want. (Again, I ignore what happens if they don’t.) I omit what that dance looks like since it doesn’t involve us. Assuming that all goes well, Google gives them an Auth Code, which the javascript on the login page sends to us.
10. We call Google’s OAuth servers to verify the Auth Code and use it to get the Auth Token and Refresh Token…
11. … which we then store in the data store…
12. … and then send back something so the Javascript page can tell the user that they can use our Action normally from now on.

Which they can now do, and it behaves as it did in the earlier, simple, scenario.

That looks complex, but it turns out that we can remove some steps in some cases. If the Google Cloud Project is the same project you use for both your Action as well as the web-based Google Sign-In, then once they authorize the project on the web, all calls to your fulfillment will include the Identity Token. This lets us remove steps 2-6 above, so things look more like this:

1. The Assistant sends the Action webhook an Intent and possible parameters. This will be the first message, so our welcome intent is triggered. There is no Identity Token.
2. The webhook sees there is no Identity Token, so we send back a message saying they need to visit our website to authorize us to access their Google services. We may require them to switch to a mobile device to do this part and even include a link to the login page. (This is the collapsed steps 2 and 6 from above.)
3. They will follow the link on a device that has a screen.
4. We’ll send back the login page, which includes a link to Login with Google. We’ve configured this button to also ask for the additional scopes we need to access their services, as well as permission to access the services on their behalf when "offline".
5. They will go through the Google Login dance, the OAuth scopes screen, and will hopefully grant all the permissions we want. (Again, I ignore what happens if they don’t.) I omit what that dance looks like since it doesn’t involve us. Assuming that all goes well, Google gives them an Auth Code, which the javascript on the login page sends to us.
6. We call Google’s OAuth servers to verify the Auth Code and use it to get the Auth Token and Refresh Token…
7. … which we then store in the data store…
8. … and then send back something so the Javascript page can tell the user that they can use our Action normally from now on.

It is also worth noting that if they visit the website before even trying out the Assistant version (ie - because of a search result or whatever they start on step 8 from the second diagram or 4 from that third diagram) and log in, then we will get their Identity Token the first time they visit us through the Assistant, and this will work just like the simple scenario.

这篇关于Google Home授权代码和Google帐户身份验证的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！