我正在尝试使用 React Native 应用程序和单独的 NodeJS/Express API 后端来理解 oauth。我明白https://github.com/adamjmcgrath/react-native-simple-auth https://github.com/adamjmcgrath/react-native-simple-auth为 React Native 应用程序提供身份验证http://passportjs.org/ http://passportjs.org/为 NodeJS 后端提供身份验证。我不确定如何连接这两者以进行登录身份验证和访问 API。

我希望用户通过电子邮件和密码或通过 Facebook/Twitter/Google 登录 React Native 应用程序。登录应用程序后，我应向 API 发送什么内容以确保它们经过身份验证并有权访问特定路由？

以下是登录并查看登录用户设置的示例流程：

1. 用户通过电子邮件/密码或 Facebook/Twitter/Google 登录 React Native 应用程序。
2. 用户已通过身份验证
3. 应用程序向 GET /api/settings 发出请求
4. API 验证用户是否经过身份验证并返回用户的设置，或者 API 验证用户未经过身份验证并返回 403。

这个问题涉及很多内容，以至于无法用一个单一的答案来解决，但这里有一些提示和总体轮廓，应该广泛适合您想要完成的任务。

OAuth2授权

听起来，您有兴趣使用 OAuth 2 提供社交登录授权，并且想做第一方验证作为使用电子邮件和密码的替代方案。对于社交登录，您最终将使用 OAuth 2 隐式流程来检索访问令牌，这是一种广泛认可的模式。因为你也在寻找认证对于拥有电子邮件和密码的用户，您可能需要熟悉 OpenID Connect，它是 OAuth 2 的扩展，除授权外还明确支持身份验证。

无论哪种情况，一旦您的用户提交了电子邮件/密码组合或通过社交身份提供商授予了权限，您将收到响应访问令牌和（可选）一个ID token。令牌，可能是 JWT（JSON Web 令牌，请参阅jwt.io http://jwt.io）将作为一个 base64 编码的字符串出现，您可以对其进行解码以检查 JWT 的结果，其中包括用户 ID 等信息以及电子邮件地址、姓名等其他详细信息。

有关不同类型流的更多信息，请参阅关于数字海洋的精彩概述 https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2.

使用令牌进行 API 身份验证

现在您已经有了访问令牌，您可以将其与所有请求一起传递到您的 API，以证明您已正确进行身份验证。您将通过在 HTTP 标头中传递访问令牌来完成此操作，特别是Authorization标头，在您的 base64 编码的访问令牌（您最初收到的响应授权请求时收到的令牌）前面加上Bearer 。所以标题看起来像这样：

Authorization: Bearer eyJ0eXAiOiJKV1QiLCJh...

在 API 方面，您将收到该令牌，对其进行解码，然后verifyID 和其中的声明。作为令牌的一部分传递sub财产将是subject，或发出请求的用户的 ID。这是您识别访问权限并开始使用相应用户权限、权限等在 API 端执行操作的方式。同样重要的是，您validate一旦您在 API 端收到访问令牌，就可以确保它不是欺骗或手工制作的。

隐式流程在 RN 中的表现如何

以下是 React Native for OAuth 2 隐式流程的一般流程，您将使用它来创建社交身份提供商：

1. 用户点击 React Native UI 上的社交登录按钮之一
2. 响应按钮的代码将根据每个提供程序的需求构建一个到这些提供程序的请求 URL（因为它们略有不同）。
3. 使用Linking在 RN 中的 API 中，您将在设备上的浏览器中打开该 URL，该 URL 将用户发送到社交提供商，以便他们进行登录/授权舞蹈。
4. 完成后，社交提供商会将用户重定向到您提供的 URL。在移动设备上，您将使用自己的自定义 URL 方案将用户从 Web 视图移至您的应用程序。该方案是您作为应用程序一部分注册的内容，例如my-awesome-app://，您传递给社交提供商的重定向 URL 可能如下所示my-awesome-app://auth_complete/. See 链接 API 文档 http://facebook.github.io/react-native/docs/linking.html了解如何配置这些 URL 方案和深层链接。
5. 在该新 URL 方案/深层链接的处理程序中，您将获得作为 URL 一部分传递的令牌。手动或使用库，从 URL 中解析出令牌并将其存储在您的应用程序中。此时，您可以开始将它们作为 JWT 检查，并将它们传递到 HTTP 标头中以进行 API 访问。

RN 中资源所有者密码授予流程的外观如何

您可以选择自己帐户的电子邮件/密码组合，坚持使用隐式流程，或切换到资源所有者密码授予流程if您的 API 和应用程序相互信任，这意味着您同时制作应用程序和 API。我更喜欢移动应用程序上的 ROPG 流程，因为用户体验要好得多——您不必打开单独的 Web 视图，只需让他们直接在应用程序中的 UI 元素中输入电子邮件和密码即可。话虽如此，它看起来是这样的：

1. 用户点击电子邮件/密码组合登录按钮，RN 会使用包含电子邮件和密码的 TextInputs 的 UI 进行响应
2. 向您的授权服务器（可能是您的 API，也可能是单独的服务器）构建一个 POST 请求，其中包括正确设计的 URL 以及传递电子邮件和密码的正文详细信息。触发此请求。
3. 身份验证服务器将在响应正文中使用关联的令牌进行响应。此时，您可以执行与之前在上述步骤 5 中执行的操作相同的操作，即存储令牌以供以后在 API 请求中使用，并检查它们以获取相关的用户信息。

正如您所看到的，ROPG 更简单，但只应在高度可信的场景中使用。

在 API 中

在 API 方面，您检查 Authorization 标头中的令牌，如前所述，如果找到，则假设用户已通过身份验证。有效和验证令牌和用户权限仍然是良好的安全实践。如果请求中没有发送令牌，或者发送的令牌已过期，则您将拒绝该请求。

当然有很多内容，但这提供了一个总体轮廓。