实施帐户关联-查询 [英] Implementing Account Linking - queries
问题描述
我正在努力在Google Actions应用上实现帐户链接时，我向Google Dev Advocate寻求帮助，他向我发送了指向我已阅读的文档文章的链接，并建议我也咨询Stackoverflow。我也已经提出了第二个建议，并且一直在努力寻找问题的确切答案，因此，我致力于在此处链接到doc文章，添加我的所有查询，然后将其发送回Dev Advocate，以期进一步澄清。 ，特别是在提醒您，有关该主题的文档可以供新手阅读，并且什么都不应理所当然。
I've asked a Google Dev Advocate for help as I'm struggling to implement Account Linking on my Google Actions app, he sent me a link to a documentation article I already had read and suggested I also consult Stackoverflow. Having already done the second suggestion too and having struggled to find the exact answers to my questions, I've deiced to link to the doc article here, add all my queries and send this back to the Dev Advocate in the hope to get more clarification, especially as a reminder that Documentation could be read by complete newbies on the topic and that nothing should be given for granted.
这是我指的文章 https://developers.google.com/actions/identity/account-linking
我在下面的查询：
- 隐式和授权代码流之间有什么区别？在选择授权代码的文章中，为什么？
- 尽管我发现上获取客户ID和机密的地方，您认为在文章中添加链接会很好吗？
- 授权URL-我没有找到明确的指南。一些 Stackoverflow票证可以报告2个Google OAUth URL使用（对于授权URL，输入 https://accounts.google.com/o/oauth2 / v2 / auth
对于令牌URL，请输入 https：// www .googleapis.com / oauth2 / v4 / token ），但最近对Google政策的更改建议
- What is the difference between implicit and authorization code flow. In the article "Authorization code" is chosen, why?
- Although I have found on Stackoverflow where to get your Client ID and secret, don't you think it would be good to add a link in the article?
- Authorization URL - this is something instead I haven't found a clear guide for. Some Stackoverflow tickets report 2 Google OAUth URLs can be used (For the Authorization URL, enter https://accounts.google.com/o/oauth2/v2/auth For the Token URL, enter https://www.googleapis.com/oauth2/v4/token), but a recent change to google policy suggests
使用OAuth实施帐户关联时，您必须拥有自己的OAuth端点
When implementing account linking using OAuth, you must own your OAuth endpoint
所以我现在非常困惑我应该在Aiuthorization URL和Token URL中输入什么-为什么没有以更基本和更清晰的方式记录此内容？我还读过它需要通过HTTPS来提供服务，如果您正在从事本地和非商业性的宠物项目，而又无法支付HTTPS费用，该怎么办？
So I'm now extremely confused at what I should put in the Aiuthorization URL and Token URL - why isn't this documented in a more basic and clear way? I've also read it needs to be served over HTTPS, what if you're working on local and on a pet project which isn't commercial and you won't be able to pay for HTTPS?
- 什么是无缝帐户链接？为什么不解释和记录该问题？
如果您的应用支持无缝帐户链接
If your app supports seamless account linking
- 我们应该在哪里将其列入白名单？
将以下重定向URI列入白名单：< a href = https://oauth-redirect.googleusercontent.com/r/ rel = noreferrer> https://oauth-redirect.googleusercontent.com/r/
- 您的OAuth 2.0客户端配置详细信息是什么？在哪里可以找到它们？
在展开的OAuth 2.0表单中，用OAuth填写字段2.0客户端配置。填充范围时，请确保它们是用空格分隔的。
In the expanded OAuth 2.0 form, fill out the fields with your OAuth 2.0 client configuration. When filling in scopes, ensure they are space delimited.
- 我不请参阅我的Oneplus 3T Google应用程序上的发现选项卡，在哪里还能找到它？
打开Google应用，然后转到发现标签。
Open the Google app and go to the Discover tab.
- 这就是我遇到的问题-与Stackoverflow上的许多其他人一样，我收到该帐户尚未链接错误。也许解决上述问题将解决帐户关联错误？
调用您的应用。由于这是第一次使用您的Google帐户调用该应用程序，因此助手会通知您必须链接您的帐户。
Invoke your app. Since it's the first time invoking the app with your Google account, the Assistant notifies you that you must link your account.
这些问题，我还有以下问题：
In addition to those questions, I also have the following:
- 我想访问用户日历和用户基本信息，所以我添加了个人资料，电子邮件和 https://www.googleapis.com/auth/calendar 是否可以确认这些信息
- I would like to get access to the user calendar and user basic info so I've added profile, email and https://www.googleapis.com/auth/calendar could you confirm these are correct?
谢谢，请记住文档应该适合每个人！
Thanks and please remember documentation should be for everyone!
推荐答案
文档是，适用于所有开发人员。但是，请记住，作为开发人员，某些任务可能需要 you 来学习比您现在知道的更多的知识。来到SO是做到这一点的方法之一，但是还有许多其他途径可以补充这一点。
Documentation is for all developers. However, keep in mind that some of the tasks might require you, as a developer, to learn more than you currently know. Coming to SO is one of the ways to do that, but there are many other avenues that supplement that.
好的原始文档确实可以帮上忙。 Google的文档目前非常糟糕-曾经很糟糕。
Good original documentation does, however, help. Google's docs are currently just bad - they used to be terrible.
更新-在我们开始之前，让我先回答一个您提出的问题，但是
Update - Before we begin, let me answer a question you suggest, but don't actually ask.
为什么我完全需要OAuth服务器？
Why do I need an OAuth server at all?
首先-不用。
请考虑一下您的服务，例如网站和助手作为浏览器。对于许多网站，他们不需要知道谁是用户才能使用该网站。网站完全可以在没有用户帐户的情况下做很多事情。
Think of your service like a website and the Assistant as a browser. For lots of websites, they don't need to know who the user is in order to use the website. There are lots of things the website can do without a user account at all.
在某些情况下，了解访问您网站的用户之前访问过您很有用。 。通常，您会使用Cookie来跟踪这样的用户。
In some cases, it is useful to know that the user visiting your website has visited you before. Frequently, you'll use a cookie to do track users like this.
助手与此等效，尽管略有不同。助手会向您发送匿名用户ID和每条消息。此用户ID仅适用于该用户和您的操作-不会再用于任何其他操作或任何其他用户。因此，如果您进行跟踪，则可以知道用户何时返回。像Cookie一样，用户可以重置或清除它，但是在大多数情况下，这是持久的。
The Assistant has an equivalent to this, although it is slightly different. The Assistant sends an anonymous UserID with each message to you. This UserID is only for this user and for your Action - it isn't re-used for any other Action or any other user. So if you track it, you'll know when the user returns. Like cookies, users can reset or clear it, but for the most part, this is durable.
但是有时候，您可能需要一个人登录一个帐户你的网页。这就是OAuth服务器要完成的任务-为用户提供一种登录您的操作的方式。 OAuth是当今人们登录服务的一种非常标准的方法，尽管其目的实际上是授权客户代表您行事。
But sometimes, you might need a person to log in to an account on your website. This is what the OAuth server is meant to accomplish - give users a way to log into your Action. OAuth is a pretty standard way to let people log into services these days, although the intent is really to authorize a client to act on your behalf.
后者确实是在这种情况下，OAuth就是在这样做-您的用户授权助手在与您的操作进行对话时代表用户执行操作。
The latter is really what OAuth is doing in this case - your user is authorizing the Assistant to act on the user's behalf when talking to your Action.
（更新-现在有些方法可以避免在某些情况下必须完全设置OAuth服务器。请参阅此答案底部的更新。）
(Update - There are now ways to avoid having to setup an OAuth server at all in some circumstances. See the update at the bottom of this answer.)
现在返回您的问题
但是...让我们回顾一下您的问题。
But... let's go over your questions.
隐式和授权代码流之间有什么区别？
What is the difference between implicit and authorization code flow.
这是OAuth2标准对两个术语进行了更仔细的定义，但总而言之-它们都让客户端（远程您的服务器上的服务器-在这种情况下为助手），以使用户授予您服务器上的某些权限。
These are two terms that are more carefully defined by the OAuth2 standard, but in short - both of them let a client (a remote server from yours - the Assistant in this case) to get a user to give certain rights on your server.
隐式流程在您需要设置的内容和两台服务器交换的内容上都比较简单，但是假定一旦您发行了令牌，它就无限期有效。这带来了更高的风险，即有人可以获取此令牌并使用它来模拟助手。
The Implicit flow is simpler, both in what you need to setup and what the two servers exchange, but assume that once you issue a token, it is indefinitely valid. This brings with it a slightly higher risk that someone can get this token and use it to impersonate the Assistant.
Auth Code流程更为复杂（尽管数量不多），并通过多种方式解决了风险。一种方式是某些事务在服务器到服务器之间完成，而不是包括客户端，并且这些事务包括共享机密。另一种方法是auth令牌的生存期有限，因此暴露窗口也有限，但是存在刷新令牌，可以用来获取新的auth令牌。
The Auth Code flow is more complex (although not a lot) and addresses the risks in several ways. One way is that some transactions are done server-to-server instead of including the client, and that those transactions include a shared secret. Another way is that the auth token has a limited lifetime, and therefore a limited window of exposure, but that there is a refresh token which can be used to get a new auth token.
在文章授权代码中被选中，为什么？
In the article "Authorization code" is chosen, why?
最可能是因为更安全，可进行最少的额外工作。但是，它解决的大多数安全问题在更开放的环境（例如浏览器和移动设备）中最为明显-使用Assistant并不会带来太大的风险。但是，对于需要设置身份验证服务器的地方，采用更安全的路由在其他方面也有好处。
Most likely because it is more secure for a minimal level of extra work. Most of the security issues it addresses, however, are most visible in more open environments such as browser and mobile - they're not as big a risk with the Assistant. However, for places that need to setup an auth server, going with the more secure route has benefits in other areas.
大多数Google API使用Auth Code流程或的变体它。 （尽管大多数使用它是从客户端而不是服务器端使用的。这是操作的帐户链接所要求的。）
Most Google APIs use the Auth Code flow or variants of it. (Although most use it from the client side - not the server side. Which is what Account Linking for Actions requires.)
在Stackoverflow上找到了获取客户ID和机密的地方，您认为在文章中添加链接会很好吗？
Although I have found on Stackoverflow where to get your Client ID and secret, don't you think it would be good to add a link in the article?
好...除了 SO答案不再有效。 （显然，这从来都不是有效的。）正如您在下一个问题中指出的那样，Google已阐明了其政策，该政策要求您拥有用于Action的OAuth端点。此外，他们进行了技术更改，使您无法使用Google的端点。 （而且我已经更新了答案，这样说来。）
Well... except that SO answer is no longer valid. (And, apparently, was never intended to be valid.) As you noted in your next question, Google has clarified their policy that requires you own the OAuth endpoints you use for an Action. They have, furthermore, made technical changes that prevent you from using Google's endpoints. (And I've updated the answer to say so.)
配置云项目部分正确无误，并介绍了如何设置与Calendar API，您不能使用Google的OAuth端点对您自己的项目进行身份验证。
While the "Configure cloud project" part is correct, and describes how you setup credentials to be used with the Calendar API, you cannot use Google's OAuth endpoints to do the auth for your own project.
所以我现在对自己的工作感到非常困惑应该放在授权URL和令牌URL中-为什么没有以更基本，更清晰的方式记录下来？
So I'm now extremely confused at what I should put in the Authorization URL and Token URL - why isn't this documented in a more basic and clear way?
他们做出的假设在文档中不太清楚。建议他们说 步骤1。配置服务器您有一台OAuth服务器。如果您已经拥有OAuth服务器，那么您应该知道服务器的授权URL和令牌URL。
Because this is a point where they're making an assumption that isn't very clear in the documentation. It is suggested where they say "Step 1. Configure your server" that you have an OAuth server. If you have an OAuth server already, then you should know what your server's Authorization and Token URLs are.
但是，如果没有，这将在下面进一步解释他们谈论确定OAuth的终结点服务您正在创建的。
If you don't, however, this does get further explained where they talk about determining what the endpoints will be for an OAuth service you're creating.
我也读过它需要通过HTTPS提供服务，如果您在本地和非商业的宠物项目上工作，并且无法支付HTTPS费用？
I've also read it needs to be served over HTTPS, what if you're working on local and on a pet project which isn't commercial and you won't be able to pay for HTTPS?
是的，必须是HTTPS。这是OAuth的要求，也是您发送可用于执行用户授权操作的令牌时的良好做法。听起来您好像希望能够向Google服务器发出API调用，并且如果这些令牌（或可用于访问相同资源的令牌）丢失，则您的Google帐户可能会受到损害。
Yes, it has to be HTTPS. This is a requirement of OAuth, and good practice when you're sending tokens that can be used to do things authorized by a user. It sounds like you want to be able to issue API calls to a Google server, and if those tokens got out (or tokens that could be used to access the same resources), then your Google Account could be compromised.
您在这里可以进行很多本地或宠物项目开发的选择。仅列举一些：
You have a lot of options here for your local or pet project development. Just to list a few:
-
您可以使用Firebase函数。对于宠物级别的项目，它们是免费的。 （而且，如果您的操作颇受欢迎，Google助手会为您提供一定程度的使用信用，以支付一定程度的使用费用。）
You can use Firebase Functions. For projects on a "pet" level, they're free. (And if your Action gets a little popular, Google Assistant will give you credits that should pay for a modest level of use.)
您可以获得SSL证书免费使用让我们加密。
You can get SSL certificates for your server for free using Let's Encrypt.
由于您的服务器必须具有公共地址，因此您可以使用 ngrok 创建隧道，该隧道也可以提供公共地址您可以使用的HTTPS地址。一旦您的项目退出个人测试阶段，这可能就不好了，但这是一个很好的开始。
Since your server has to have a public address, you can create a tunnel using ngrok, which also provides a public HTTPS address you can use. This probably isn't good once your project gets out of the "personal testing" stage, but is a good tool to start with.
当然还有其他方法，但是可以根据需要使用一些好的工具。
There are other approaches, of course, but these are a few good tools that you can use depending on your needs.
什么是无缝帐户链接，为什么不解释和记录？
What is Seamless Account Linking and why isn't this explained and documented?
它是。除了文档中的内容外，他们还通过 称其为简化的身份流来混淆事物。
It is. Except in the documentation they confuse things by also calling it "Streamlined Identity Flow".
在帐户链接概述页面，其中显示有关详细信息，请参见简化的身份流程，其中介绍了如何配置OAuth服务器以支持Google Assistant上的无缝身份体验。
On the Account Linking Overview page it says "For more information, see Streamlined Identity Flows about how to configure your OAuth server to support the seamless identity experiences on the Google Assistant."
这将带您到一个页面，讨论该流程如何在其他两个身份流之上构建，并具有一些其他要求，但应使用户的体验更好。
This takes you to a page talking about how this flow builds on top of the other two identity flows and has some additional requirements, but should make the user's experience better.
但是...对此不必太担心。如果您只是为了好玩而已，那么正常的身份流就不是那么大的负担。如果您要针对商用产品执行此操作，请首先使正常流程正常工作。
However... don't worry so much about this. If you're just doing this for fun, the normal identity flows aren't that much of a burden. If you're doing this for a commercial product - get the normal flows working first.
我们应该在哪里将此白名单？
将以下重定向URI列入白名单： https://oauth-redirect.googleusercontent.com/r /
这是OAuth的基本概念之一-作为客户端服务器与服务器之间通信的一部分，当您完成对用户的身份验证并获得其颁发令牌的权限后，它将说重定向到特定的URL。
This is one of the underlying concepts of OAuth - as part of the communication between the client server and your server, it will say to redirect to a particular URL when you're done authenticating the user and getting their permission to issue a token.
OAuth规范 requires ，您可以将该重定向URL与已为该客户端设置的URL进行比较。它没有指定您如何设置。因此Google说：当您为客户端设置OAuth服务器时，这是我们将要求您重定向到的URL。
The OAuth spec requires you to compare that redirect URL to a URL that has already been setup for that client. It does not specify how you set that up. So Google is saying "When you setup the OAuth server for our client - here is the URL that we will ask you to redirect to."
Google无法回答将其列入白名单（在您的OAuth服务器中除外）。大多数OAuth服务器都可以配置多个客户端，这是您要为该客户端设置的值之一。 （ClientID和ClientSecret是其他值，但Google可以让您确定这些值，并将其作为操作控制台中帐户链接配置的一部分告诉您。这是您的下一个问题。）
Google can't answer where to whitelist this except "in your OAuth server". Most OAuth servers have a way to configure multiple clients, and this is one of the values you'll set for that client. (The ClientID and ClientSecret are other values, but Google lets you determine these values and tell it as part of the configuration for Account Linking in the Action Console. Which is your next question.)
您的OAuth 2.0客户端配置详细信息是什么？
What are your OAuth 2.0 client configuration details? Where can they be found?
再次，这取决于您的 OAuth服务器和您的您想要 在用户尝试登录服务器时提示他们的要求。 ClientID和ClientSecret是两个这样的参数。助手应请求访问的OAuth范围是其他参数。但这取决于您-因为它们正在尝试访问您的服务器。
Again, this depends on your OAuth server and your requirements for what you want to prompt the user when they try to login to your server. The ClientID and ClientSecret are two such parameters. The OAuth scopes that the Assistant should request access to are other parameters. But these are up to you - because it is your server they are trying to get access to.
我看不到发现选项卡在我的Oneplus 3T Google App上，我还能在哪里找到它？
I don't see the Discovery tab on my Oneplus 3T Google App, where else can I find it?
该文档看起来不正确。我认为应该说您应该在移动设备上打开 Google主页应用。
That documentation looks incorrect. I think that should say that you should open the Google Home app on your mobile device.
这也有可能意味着Google应用程序，则您的手机可能不支持Google助手作为Google应用程序的一部分。您可以分别下载Google助手
It is also possible that it does mean the Google app, in which case your phone may not support the Google Assistant as part of the Google app. You can download the Google Assistant separately, if necessary.
但是-使用模拟器进行初始测试。尽管这需要一些手动步骤，但它们很容易遵循并帮助您跟踪事物。
However - use the simulator to test initially. Although it requires a few manual steps, they are easy to follow and help you trace things.
这就是我遇到的麻烦-数量很多其他人在Stackoverflow上收到帐户尚未链接错误。也许解决上述问题可以解决帐户关联错误？
This is where I get stuck - as many other people on Stackoverflow I get "The account is not linked yet" error. Maybe resolving the issues above will resolve the Account Linking error?
嗯，您的帐户尚未关联。 {：
Well, your account isn't linked yet. {:
听起来您还没有为Action设置身份验证服务器。
It sounds like you haven't set an auth server for your Action. Until you get an auth server working, the rest isn't going to work.
我想访问用户日历和用户基本信息，因此我添加了个人资料，电子邮件和 https://www.googleapis.com/auth/日历，您可以确认这些设置正确吗？
I would like to get access to the user calendar and user basic info so I've added profile, email and https://www.googleapis.com/auth/calendar could you confirm these are correct?
首先，请记住，整个过程是将用户的助手帐户到他们在您的服务上的帐户。您可能会在他们的帐户中（通过您的服务获得）您用于执行操作的信息-例如访问Google资源或访问您对它们了解的其他信息。
First of all, keep in mind that this whole process is to link the user's Assistant account to their account on your service. You may have information in their account (on your service) that you use to do things - such as access Google resources or access other things that you know about them.
此是不是的直接途径，您可以访问他们用来与助手交谈的Google帐户。
This is not directly a way that you gain access to the Google account that they're using to talk to the Assistant.
用户有权访问其在Google服务器上的资源，则需要让他们授权您的服务器的访问权限。再次使用OAuth完成此操作，但是这次您是客户端。用户将需要转到您的服务器，您将其重定向到Google的服务器以授权您，并且他们将使用需要存储的代码重定向回您的服务器。这一切都在助手外部完成，并且是帐户关联系统。
In order to get a user's permission to access their resources on Google's servers, you'll need to get them to authorize your server permission to access that. That is done using OAuth, again, but this time you're the client. User's will need to go to your server, you'll redirect them to Google's server to authorize you, and they'll be redirected back to your server with codes that you will need to store. This is all done outside of the Assistant and it's Account Linking system.
也就是说，对于您想要的，个人资料和电子邮件是相当普通的请求范围。 日历API文档确认 https ：//www.googleapis.com/auth/calendar 范围是访问该API所需要的。 （请记住，此URL不是您在浏览器中使用的URL，也不是您访问任何内容的URL，它只是一个唯一的标识名称。）
That said, for what you want, profile and email are fairly normal scopes to request. The Calendar API Documentation confirms that the https://www.googleapis.com/auth/calendar scope is what you need to access that API. (Keep in mind that this URL is not one that you'd use in a browser or that you'd go to to access anything - it is a uniquely identifying name only.)
更新以反映API更改。自从最初写出此答案以来，Google引入了 Google登录助手，这样一来，当您希望将操作绑定到在助手上使用的相同Google帐户时，就不必设置自己的OAuth服务器。如果用户允许，您可以通过这种方式获取简单的用户个人资料信息，然后可以利用它来访问其他API（同样，在用户许可的情况下）。 查看此SO答案，其中讨论了如何使用它来访问Google的其他API。
Update to reflect API Changes. Since this answer was originally written, Google has introduced Google Sign In for Assistant, which lets you avoid having to setup your own OAuth server when you are willing to tie operations to the same Google account they use on the Assistant. If the user permits, you can get simple user profile information this way, and you can then leverage this to get access to other APIs (again, with the user's permission). See this SO answer that discusses how to use this to access Google's other APIs.
谢谢，请记住文档应该适合所有人！
Thanks and please remember documentation should be for everyone!
从我与Google的对话中助理团队，他们 希望简化文档编制工作，并希望他们会把您的许多建议牢记在心。我希望这些澄清对您（以及其他遇到类似问题的人）有所帮助。
From my conversation with Google's Assistant team, they are looking to make documentation easier, and hopefully they will take many of your suggestions to heart. I hope these clarifications have helped you (and anyone else who gets here with similar problems.)
这篇关于实施帐户关联-查询的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
