我希望允许用户使用Google登录我的移动应用程序。如果用户已在其设备上登录Google，则我不希望他们重新输入用户名和密码（本地登录体验＆＃39;）。用户登录后，可以访问我服务器上的私人资源。为此，我使用的是OpenID Connect implicit flow。这就是我理解流程的方式：
1）用户正在使用我的移动客户端应用程序（ios或android）并选择使用Google登录。
2）我的客户端应用程序（使用Googles ios或android SDK）获得access_token和id_token（假设用户已安装Google+应用，已经登录并已获得我的许可）应用程序）。
3）我的客户端应用程序将access_token和/或id_token发送到我的服务器。
4）我的服务器verifies the access_token和/或verifies the id_token
5）使用任一令牌，我的服务器将google用户映射到我自己的数据库中的用户。
5）我的服务器创建自己的新安全令牌并将其返回给我的客户端应用程序。
6）我的客户端应用程序在后续的服务器请求中使用新的安全令牌来访问私有资源。
问题：
如果我想为用户提供本地登录体验，这是用于登录的正确流程吗？
假设我遵循所有googles指南（例如使用SSL，在标头或POST数据中发送令牌，正确验证令牌）......
从客户端发送access_token有哪些漏洞？
从客户端发送id_token会有哪些漏洞？
此流程还有哪些其他安全风险？
这似乎是一个非常常见的用例。这是大多数应用程序正在做的事情，以实现本地身份验证＆＃39;与谷歌？应用程序的示例将不胜感激。
提前致谢。
答案 0 :(得分：0)
也许不是一个完整的答案，而是我对此的想法：我认为发送access_token存在潜在的风险，因为服务器可以存储它（增加盗窃风险）和/或在没有SSL的情况下将其发送到其他地方然后暴露access_token ，不是吗？由于Google指南（例如SSL使用）不是强制性的（不可能，但无法检查），因此指南中的每个潜在用途都是危险的。不是风险，你可以避免，但无论如何风险。我还没有看到access_token的服务器存储指南。
答案 1 :(得分：0)
每当客户端将ID令牌传递给服务器（包括来自隐式流的所有ID令牌）时，服务器必须完全验证它。
Google有一些关于如何验证ID令牌的文档，请参阅：
如果服务器也直接从客户端处理访问令牌（即不使用服务器流），那么它应该验证它们也属于正确的用户。 ID令牌声明at_hash可用于verify that the access token does belong to the same user identified in the ID Token。
如果您使用服务器（也称为“代码”）流，那么服务器将从客户端传递code，并直接在令牌端点进行交换，并显示其客户端密钥所以。以这种方式获得的ID令牌和访问令牌无需验证，因为它们直接来自Google。