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

问题描述

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

我看过

• 您有一个某种类型的数据存储，您将在其中存储用户的身份验证令牌和刷新令牌.我将假设您使用 Google 的用户 ID 作为此数据存储的索引.

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

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

• 您有一个 Web 服务器，其中包含一些用于我们目的的重要 URL:

  • 用于实现 Action 的网络钩子.
  • 登录/身份验证页面.
  • 登录页面上的 javascript 将向您发送验证码的端点.

• 可能在 Google Home 或移动设备上运行的 Google 助理.我们还假设用户将能够访问浏览器来查看他们授权的内容.

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

让我们从用户之前登录并授权我们代表他们访问服务的情况开始.我们的数据存储中有他们的 Auth Token 和 Refresh Token，根据他们的 Google 用户 ID 编制索引.这是一个简单的案例，但它有助于我们理解所有数据如何进入的更复杂的案例.

数据流看起来像这样:

1. Assistant 向 Action webhook 发送 Intent 和可能的参数.如果这是第一条消息，这是一个受欢迎的意图，但这并不重要.它包括一个身份令牌，我们需要对其进行解码和验证.作为我们在解码时获得的数据的一部分，它包括用户的用户 ID.
2. 使用用户 ID...
3. ...我们从数据存储中获取身份验证令牌和刷新令牌.
4. 使用身份验证令牌和刷新令牌，我们可以代表用户对 Google 的服务执行一些操作.
5. 我们将从服务中获取一些结果......
6. ...我们通常希望以某种形式传回给用户.

很简单，对吧?但是如果用户之前从未使用过助手与我们的 Action 对话怎么办?并且从未授权我们访问他们的 Google 服务，所以我们没有他们的令牌?该流程看起来更像这样:

1. Assistant 向 Action webhook 发送 Intent 和可能的参数.这将是第一条消息，因此我们的欢迎意图被触发.没有身份令牌.
2. Webhook 发现没有身份令牌，因此它发回一条消息，请求登录"帮助程序功能.由于您的项目已配置为使用 Google 登录，因此 Google 助理会提示用户是否可以向您提供他们的个人资料信息.
3. 如果他们说是，您将收到另一条回复，说明他们已登录并包含身份令牌，我们会对其进行解码和验证并获取他们的用户 ID.(如果他们说不，我们会收到回复说它失败了.你如何处理这是另一回事.我假设他们说是.)
4. 使用用户 ID...
5. ...我们尝试从数据存储中获取身份验证令牌和刷新令牌.但他们还没有授权我们.我们已经认证他们，但没有授权...
6. ...所以我们发回一条消息，说他们需要访问我们的网站才能授权我们访问他们的 Google 服务.我们可能会要求他们切换到移动设备来完成这部分工作，甚至包括指向登录页面的链接.
7. 他们将在有屏幕的设备上点击链接.
8. 我们会发回登录页面，其中包含登录 Google 的链接.我们已将此按钮配置为还要求我们提供访问他们服务所需的额外范围，以及在离线"时代表他们访问服务的权限.
9. 他们将通过 Google 登录舞蹈、OAuth 范围屏幕，并有望授予我们想要的所有权限.(同样，如果他们不这样做，我会忽略会发生什么.)我省略了那支舞的样子，因为它不涉及我们.假设一切顺利，Google 会为他们提供一个 Auth Code，登录页面上的 javascript 会将其发送给我们.
10. 我们调用 Google 的 OAuth 服务器来验证 Auth Code 并使用它来获取 Auth Token 和 Refresh Token...
11. ……然后我们将其存储在数据存储中……
12. …然后发回一些东西，这样 Javascript 页面就可以告诉用户，从现在起他们可以正常使用我们的 Action.

他们现在可以执行的操作，并且其行为与之前的简单场景中一样.

这看起来很复杂，但事实证明在某些情况下我们可以删除一些步骤.如果 Google Cloud 项目与您用于操作和基于网络的 Google 登录的项目相同，那么一旦他们在网络上授权该项目，对您的实现的所有调用都将包含身份令牌.这让我们可以删除上面的步骤 2-6，所以事情看起来更像这样:

1. Assistant 向 Action webhook 发送 Intent 和可能的参数.这将是第一条消息，因此我们的欢迎意图被触发.没有身份令牌.
2. 网络钩子发现没有身份令牌，所以我们发回一条消息，说他们需要访问我们的网站才能授权我们访问他们的 Google 服务.我们可能会要求他们切换到移动设备来完成这部分工作，甚至包括指向登录页面的链接.(这是上面折叠的第 2 步和第 6 步.)
3. 他们将在有屏幕的设备上点击链接.
4. 我们会发回登录页面，其中包含登录 Google 的链接.我们已将此按钮配置为还要求我们提供访问他们服务所需的额外范围，以及在离线"时代表他们访问服务的权限.
5. 他们将通过 Google 登录舞蹈、OAuth 范围屏幕，并有望授予我们想要的所有权限.(同样，如果他们不这样做，我会忽略会发生什么.)我省略了那支舞的样子，因为它不涉及我们.假设一切顺利，Google 会为他们提供一个 Auth Code，登录页面上的 javascript 会将其发送给我们.
6. 我们调用 Google 的 OAuth 服务器来验证 Auth Code 并使用它来获取 Auth Token 和 Refresh Token...
7. ……然后我们将其存储在数据存储中……
8. …然后发回一些东西，这样 Javascript 页面就可以告诉用户，从现在起他们可以正常使用我们的 Action.

还值得注意的是，如果他们在试用 Google 助理版本之前访问该网站(即 - 由于搜索结果或他们从第二个图表的第 8 步或第三个图表的第 4 步开始)并登录，然后我们将在他们第一次通过助手访问我们时获取他们的身份令牌，这将像简单的场景一样工作.

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屋！