google-app-engine - 使用Google Cloud Endpoints进行机器对机器的身份验证

Question

语境

已使用Google Cloud Endpoints（Python）创建了一个API，许多低功耗设备将使用该API进行GET / POST数据。

与API的唯一通信将来自这些自定义设备（我拥有通信的两端）。

研究

查看身份验证，希望它像使用SSL / TLS客户端证书一样简单：


无论如何，每个远程设备都将具有由单个项目CA签名的客户端证书。
Google云端点要求SSL。


但是，似乎仅支持oauth2。我正在寻找一种“干净”的方式来实现“越区切换”身份验证，理想情况下是利用客户端设备上已经具有的客户端SSL证书。

我已经研究过创建“服务” oauth2帐户，但是由于要防止某个设备欺骗其他设备（不接受所有一组凭据），我需要为每个客户端设备生成一个服务帐户，在API端维护笨重且可怕。

似乎我迫在眉睫，需要在我的代码中为每种API方法添加一层身份验证，这在某种程度上抵消了利用Google的云端点服务的观点。

问题...最后


有没有人在针对Google的云端点大规模验证“移交”机器对机器设备的经验？
有谁知道在Oauth2身份验证过程中以GCE支持的方式使用客户端证书的方法吗？
我唯一的选择是基于POST / GET标头中的某些加密数据在API方法中进行自定义身份验证。 （或者只是转向使用Apache / NGINX和客户端证书身份验证托管API？）


问候，
马特

Answer 1

我给你写了一篇文章：

考虑到Cloud Endpoints基本上存在于OSI模型的应用程序层中，因为它通过HTTPS请求进行通信（它在TLS会话中发送HTTP请求）。端点是否使用HTTP或HTTPS都不是开发人员可配置的选项-它必须是HTTPS。

它使用HTTPS，因为API服务器具有用于认证API服务器的TLS证书。在安全连接内部，还防止RPC参数和响应被窃听。这是端点与TLS“交互”的程度-它使用它来建立会话并在此会话内发送HTTP请求。

因此，已经可以告诉您，在连接建立阶段，您将无法使用TLS客户端证书（不是常用功能）来由端点自动对API客户端进行身份验证。 Endpoints API服务器根本不会查看或请求TLS客户端证书。

现在，虽然可以通过API服务器的TLS证书来确保对API服务器本身的身份验证，但可以通过Client IDs或Users API完成API客户端的身份验证，这些代码位于您的代码中，并抽象了App Engine在以下位置提供的不同身份验证选项：当下：


OAuth（2.0）
OpenID


因此，为了以两种方式之一对您的客户端设备进行身份验证并仍然利用Cloud Endpoints，您将需要为每种设备找到一种执行OAuth流或OpenID流的方法，而您的系统已经为该设备最初部署时的相应auth方法。

Google（应用程序）帐户选项

这将涉及为每个设备创建一个Google帐户（Google的统一SSO）或由自定义域管理的Google Apps帐户，并将这些帐户的凭据提供给每个相应的设备。您可以在常规here中了解有关自定义域身份验证和App Engine身份验证配置的更多信息。

OpenID选项（general doc on OpenID with GAE）

这将涉及使用pyoidc之类的OpenID连接库在GCE实例上设置自己的OpenID提供程序，以便您可以自己设置帐户，也可能涉及向每个设备的已知OpenID提供程序注册帐户。第一个解决方案更强大，但更耗时（OpenID提供程序可以暂时关闭或永久停用，然后您的IOT网络就不走运了）。

使用客户端ID的第三种选择

您当然可以生成“已安装的应用程序”客户端ID /秘密，并将其分发到网络中的每个设备。他们可以使用它来验证自己是否是网络设备（而不是攻击者的便携式计算机），然后您信任设备，以便在每个API调用中将自己的ID准确地报告为参数。根据设备的可破解程度以及打算分发它们的范围，此方案不一定会阻止设备欺骗彼此的ID，尽管根据ID生成方案的不同，您可能会很难（每个ID都很长）。足够长的哈希值）。

如果您选择这条路线并且确实对此感到担心，则可以为每个设备设置一个客户端ID，但是谁知道您是否会对每个应用程序的客户端ID数量达到某种未记录的限制，这也需要您可以手动执行此操作，也可以编写脚本来登录无头浏览器中的开发控制台并执行所需的操作。

实际使用TLS客户端证书的第四个疯狂选项

如果您确实打算同时使用TLS客户端证书进行身份验证和使用Cloud Endpoints作为API，则可以尝试在请求中发送客户端证书，因为TLS正在加密请求数据（除非您的攻击者找到了一种有效的方法解决离散离散对数的反问题，在这种情况下，他们可能会太忙于攻击更重要的目标（无攻击）并永远更改信息安全游戏），然后以某种方式在端点方法中读取和认证证书（第三方为此，可能需要使用随应用程序上传的库。

如果您对TLS客户端证书有一定的了解，则是第四个现实选择

从App Engine切换到Compute Engine，您基本上可以在同一数据中心管理和托管VM。在此框中，您可以在喜欢的任何端口上实现任何类型的连接协议，因此您可以基于连接设备的客户端证书对传入的API请求（而非端点，通知）进行TLS身份验证。

祝好运！