使用 React Native 和 API 后端进行身份验证

问题描述

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

I'm trying to wrap my head around oauth with a React Native app and a separate NodeJS/Express API backend. I understand https://github.com/adamjmcgrath/react-native-simple-auth offers authentication for a React Native app and http://passportjs.org/ offers authentication for a NodeJS backend. I'm unsure how to connect these two for authentication for login and access to the API.

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

I'd like users to login to the React Native app either by email and password or via Facebook/Twitter/Google. Once logged into the app, what do I send to the API to make sure they are authenticated and have access to a specific route?

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

Here is an example flow to login and see the logged-in user's settings:

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

推荐答案

这个问题有很多，太多了，以至于无法在一个 SO 答案中全部解决，但这里有一些提示和大纲应该大致适合您想要完成的工作.

There's a whole lot to this question, so much so that it wouldn't all fit in a single SO answer, but here's some tips and a general outline that should broadly fit into what you want to accomplish.

从它的声音来看，您有兴趣使用 OAuth 2 来提供社交登录授权，并希望使用第一方身份验证作为替代方案电子邮件和密码.对于社交登录，您最终将使用 OAuth 2 隐式流程来检索访问令牌，这是一种广泛认可的模式.由于您还希望使用电子邮件和密码对用户进行身份验证，因此您可能需要熟悉 OpenID Connect，它是 OAuth 2 的扩展，除了授权之外还明确支持身份验证.

From the sounds of it, you are interested in using OAuth 2 to provide social login authorization, and would like to do first-party authentication as an alternative with an email and password. For social logins you will end up using the OAuth 2 Implicit flow to retrieve an access token, which is a widely recognized pattern. Because you are also looking to authenticate users with an email and password, you may want to familiarize yourself with OpenID Connect, which is an extension of OAuth 2 and which explicitly supports authentication in addition to authorization.

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

In either case, once your user has either submitted an email/password combo or granted permission through the social identity providers, you will receive in response an access token and (optionally) an ID token. The tokens, likely a JWT (JSON Web Token, see jwt.io) will come across as a base64 encoded string that you can decode to inspect the results of the JWT, which will include things like the ID of the user and other details like email address, name, etc.

有关不同类型流的更多信息，请参阅有关数字海洋的精彩概述.

For more info on the different types of flows, see this excellent overview on Digital Ocean.

现在您有了一个访问令牌，您可以将它与所有请求一起传递给您的 API，以证明您已正确进行身份验证.为此，您将在 HTTP 标头中传递访问令牌，特别是 Authorization 标头，在 base64 编码的访问令牌(最初为响应您的授权请求而收到的)之前使用 承载.所以标题看起来像这样:

Now that you have an access token, you can pass it along with all requests to your API to demonstrate that you have properly authenticated. You'll do this by passing along the access token in your HTTP headers, specifically the Authorization header, prefacing your base64-encoded access token (what you originally received in response to your authorization request) with Bearer. So the header looks something like this:

授权:持有人eyJ0eXAiOiJKV1QiLCJh...

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

On your API's side, you will receive that token, decode it, and then verify the ID and claims in it. Passed as part of the token in the sub property will be the subject, or ID of the user making the request. This is how you identify access and start to do things on your API side with the respective user's rights, perms, etc. It is also important that you validate the access token once you receive it on your API side, to ensure it wasn't spoofed or hand-crafted.

以下是用于 OAuth 2 隐式流的 React Native 中的一般流程，这是您将用于社交身份提供商的流程:

Here's what the general process looks like in React Native for OAuth 2 Implicit flows, which is what you'll use for social identity providers:

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

1. User taps one of your social login buttons on React Native UI
2. Your code that responds to the buttons will build a request URL to those providers, depending on what each wants (because it differs slightly).
3. Using the Linking API in RN, you will open up that URL in a browser on the device which sends the user off to the social provider for them to do the login/authorization dance.
4. Once complete, the social provider will redirect the user to a URL you provider. On a mobile device, you will use your own custom URL scheme to move the user from the web view to your app. This scheme is something you register as part of your app, such as my-awesome-app://, and the redirect URL you pass to the social provider could look like my-awesome-app://auth_complete/. See the Linking API docs for how to configure these URL schemes and deep linking.
5. In the handler for that new URL scheme/deep link, you'll get the tokens passed as part of the URL. Either by hand or using a library, parse out the tokens from the URL and store them in your app. It's at this point that you can start inspecting them as JWTs, and pass them along in the HTTP headers for API access.

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

您可以为自己的帐户选择电子邮件/密码组合，要么坚持使用隐式流程，要么切换到资源所有者密码授予流程如果您的 API 和应用受到每个人的信任其他，这意味着您正在制作应用程序和 API.在可能的情况下，我更喜欢移动应用程序上的 ROPG 流程，因为 UX 更好——您不必打开单独的 Web 视图，您只需让他们直接在应用程序的 UI 元素中输入他们的电子邮件和密码即可.话虽如此，这就是它的样子:

How it looks in RN for Resource Owner Password Grant flows

You have the option for your email/password combo for your own accounts of either sticking with the Implicit flow, or switching to the Resource Owner Password Grant flow if your API and app are trusted by each other, meaning that you are making both the app and the API. I prefer the ROPG flow on mobile apps where possible because the UX is much nicer--you don't have to open up a separate web view, you just have them type in their email and password into UI elements directly in the app. So that being said, here's what it looks like:

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

如您所见，ROPG 更加简单明了，但只能用于高度可信的场景.

As you can see, the ROPG is more straightforward, but should only be used in highly trusted scenarios.

在 API 端，您检查 Authorization 标头中的令牌，如前所述，如果找到，则假定用户已通过身份验证.验证和验证令牌和用户权限仍然是一种很好的安全做法.如果没有随请求发送的令牌，或者发送的令牌已过期，则拒绝请求.

On the API side, you inspect for the token in the Authorization header, and as mentioned previously, and if found you assume that the user has been authenticated. It is still good security practice to valid and verify the token and user permissions. If there is no token sent with the request, or if the token sent has expired, then you reject the request.

希望有帮助！它当然有很多，但这提供了一个大纲.

Hope that helps! There's certainly a ton to it, but that provides a general outline.

这篇关于使用 React Native 和 API 后端进行身份验证的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！