这个问题有很多问题，以至于不能用一个简单的答案来回答，但是这里有一些技巧和一个大致的大纲，应该可以广泛地适合你想要完成的事情。

OAuth2授权

听起来，您对使用OAuth 2提供社交登录 * 授权 * 感兴趣，并且希望使用第一方 * 验证 * 作为使用电子邮件和密码的替代方案。对于社交登录，您最终将使用OAuth 2隐式流来检索访问令牌，这是一种广泛认可的模式。因为您还希望使用电子邮件和密码 * 验证 * 用户，您可能需要熟悉OpenID Connect，它是OAuth 2的扩展，除了授权之外还显式支持身份验证。
无论哪种情况，一旦您的用户提交了电子邮件/密码组合或通过社交身份提供商授予权限，您将收到 * 访问令牌 * 和（可选）一个 *ID标记 *。标记，可能是JWT（JSONWebToken，请参见jwt.io）将以base64编码字符串的形式出现，您可以对其进行解码以检查JWT的结果，其中包括用户的ID以及电子邮件地址、姓名等其他详细信息。
有关不同类型流的详细信息，请参见this excellent overview on Digital Ocean。

使用令牌进行API身份验证

现在您有了一个访问令牌，您可以将它与所有请求沿着传递给API，以证明您已经正确地进行了身份验证，您可以通过在HTTP头中传递访问令牌来实现这一点，具体来说就是Authorization头。为base64编码的访问令牌添加前缀（您最初收到的对授权请求的响应）与Bearer匹配。
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJh...
在API端，您将接收令牌，对其进行解码，然后验证ID和其中的声明。作为令牌的一部分在sub属性中传递的将是 subject，或发出请求的用户的ID。这就是您如何识别访问并开始在API端使用相应用户的权限、perms同样重要的是，一旦在API端收到访问令牌，就必须验证它，以确保它不是伪造的或手工制作的。

隐式流在RN中的外观

以下是React Native for OAuth 2隐式流的一般流程，您将使用该流程作为社交身份提供者：
1.用户点击React Native UI上的一个社交登录按钮
1.响应这些按钮的代码将根据每个提供程序的需要（因为它们略有不同）构建一个到这些提供程序的请求URL。
1.使用RN中的Linking API，您将在设备上的浏览器中打开该URL，然后将用户发送到社交提供商，让他们进行登录/授权。
1.完成后，社交提供商将用户重定向到您提供的URL。在移动的设备上，您将使用自己的自定义URL方案将用户从Web视图移动到您的应用。此方案是您注册为应用的一部分的方案，例如my-awesome-app://。而你传递给社交网站的重定向URL可能看起来像my-awesome-app://auth_complete/。有关如何配置这些URL方案和深度链接，请参见the Linking API docs。
1.在新URL方案/深度链接的处理程序中，您将获得作为URL一部分传递的令牌。手动或使用库，从URL中解析出令牌并将其存储在应用中。此时，您可以开始将其作为JWT进行检查，并在HTTP头中沿着以供API访问。

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

你可以选择你自己账户的电子邮件/密码组合，要么坚持隐式流程，要么切换到资源所有者密码授予流程 * 如果 * 你的API和应用程序相互信任，这意味着你同时制作应用程序和API。我更喜欢移动的应用程序上的ROPG流程，因为UX更好--你不必打开一个单独的网页视图，你只需要让他们直接在应用程序的UI元素中输入他们的电子邮件和密码。也就是说，它看起来是这样的：
1.用户点击电子邮件/密码组合登录按钮，RN使用包含电子邮件和密码文本输入的UI响应
1.向您的授权服务器（可能是您的API，也可能是单独的服务器）构建POST请求，该请求包含巧尽心思构建的URL以及随电子邮件和密码一起传递的正文详细信息。
1.认证服务器将在响应正文中使用关联的令牌进行响应。此时，您可以执行与上述步骤5相同的操作，即存储令牌以供稍后在API请求中使用，并检查令牌中的相关用户信息。
正如您所看到的，ROPG更加直接，但是应该只在高度可信的场景中使用。

在API

在API端，检查Authorization头中的令牌，如前所述，如果发现，则假定用户已通过身份验证。验证令牌和用户权限并使其有效仍然是一种良好的安全实践。如果没有随请求发送令牌，或者发送的令牌已过期，则拒绝请求。
当然有一吨，但这提供了一个大致的轮廓。