我是否不需要使用OAuth 2访问令牌来保护我的API端点（资源）？

Question

OAuth2对话中涉及多个参与者。考虑一下  以下文章here

中的图表

请注意，我的应用程序包含restaurants的数据，并且具有与之相关的API。我们称之为restaurant的API。让我们在这个例子的上下文中为每一方分配一些角色

User - our chefs, who have some recipes in restaurant

Application - Web client written in HTML5, JS, CSS that our Users use to interact with APIs

OAuth Endpoint - Google (who acts as Authorization Server)

API - My application API keeping all data for chefs  

Implicit的工作流程（根据链接中的上图）说明Application获取access token，然后Application（浏览器）调用{{1} （我的应用程序与厨师食谱）并获取数据。

问题

• 我不应该API我的应用端点，或者只是相信secure？是的，信任是在accesssTokens和Application（Google）之间建立的，但OAuth Endpoint已trust API和Application确认了accessToken的有效性1}}与OAuth Endpoint（Google）？

• 如果我应该保护我的应用程序API端点，我的应用程序接受/login的{​​{1}}是否应该有APIs端点，验证并创建accessTokens基于标头的客户端用于与JWT等受保护资源进行进一步通信。

期待您的想法。
提前致谢

Answer 1

TL; DR - 不要盲目信任访问令牌。要求Google透露与其关联的用户/电子邮件以及生成它们时使用的客户端ID。您仍然可以提供/login端点，主要用于扩展性目的。

让我们首先处理核心安全性

OAuth是委派协议，而不是身份验证协议。引用the OAuth website：

  

OAuth 2.0规范定义了委托协议[...] OAuth用于各种应用程序，包括提供用户身份验证机制。 [...]让我们再说一遍，明确：

     

OAuth 2.0不是身份验证协议。

因为它不是身份验证协议，所以您的app / API永远不会知道用户是谁。它只是一个令牌。在此上下文中的委派意味着OAuth允许App A请求访问App B中属于用户的资源，方法是让用户向App B进行身份验证，然后将令牌传递回App A.在您的示例中，它可以提供您的Web可以访问 Google资源的应用（电子邮件，照片等 - 取决于用户所拥有的所需scope）（主厨）。

请注意，这不是您在此处所做的，因为您正在访问由您的应用管理的资源，而不是Google。特别是，正如您正确识别的那样，访问令牌对您的API没有任何意义。我也可以给它一个随机字符串。

您可能想要使用以下方案：

• 按照问题中的描述实施隐式方案。
• 让API服务器通过Google验证访问令牌，并向Google询问与令牌关联的名称或电子邮件。这将是实际登录Google的用户的身份，然后您可以决定是否向该用户授予权限。

此方法存在的问题是，许多应用都会将OAuth与Google结合使用，因此许多应用都会拥有不属于您应用的Google访问令牌。你怎么能分辨出来呢？

当您使用访问令牌向Google提供访问令牌时，您可以向Google提供生成此令牌时提供的客户端ID （请参阅图表指示客户端ID的方式）已发送？）。由于该客户端ID可以唯一标识您的应用，因此您的API可以告诉您已经提供了仅来自您的应用的令牌。请注意，OAuth流程的这一关键部分在移动应用程序中非常不同，这就是为什么隐式流程不应该与移动应用程序一起使用（但对于Web应用程序来说很好）。

请注意，您的客户端ID应该被视为常识（例如，它可以在执行此流程的计算机上的.js文件中找到），但它不能被欺骗，因为作为OAuth流程的一部分，用户的浏览器将被重定向到在Google中预先配置且属于您的应用的网址。因此，即使恶意应用使用您的客户ID，Google仍会将令牌发送到您的应用。

其他实用性

以上要求您在每次API调用时向Google发出调用，或者至少缓存有效的访问令牌（这意味着您保持状态，这对于可伸缩性来说是一个无聊的事）。如果要避免这种情况，可以创建生成JWT的/login端点。请注意，您仍需要在登录时验证访问令牌。