从Google / Facebook帐户重新验证用户

Question

所以我需要创建一个REST API来为IOS应用程序提供功能。我们允许用户只使用普通帐户或使用 Facebook / Google登录进行注册。

我最近一直在阅读OAuth，我想我理解在我的情况下（当用户使用 Facebook / Google登录）在我的应用中注册帐户时如何使用OAuth的过程：

1. 我向各种社交提供商（例如FB / Google）注册我的IOS应用程序。我最终得到了我安全存储在后端的客户端ID /客户端密钥。
2. 现在，用户点击该应用上的社交登录按钮，该按钮会将用户重定向到社交网站进行登录，并授予我的应用使用其社交帐户的权限。
3. 社交oauth提供商会使用授权码将用户重定向回我的服务器。
4. 一旦我的服务器拥有授权代码，我将使用该客户端ID和密码（或任何其他需要的特定凭据）从社交oauth提供商处检索访问令牌。
5. 现在我拥有了用户的访问令牌，可以在一段时间内使用他们的社交资源（yay）。
6. 一旦我拥有了社交访问令牌，我就会为应用程序发出生成的访问令牌，以便在向我的REST API发出请求时（该应用程序只会从现在开始与我的REST API通信）。

我的问题：

• 上述过程是一个好习惯吗？
• 让我们说用户从应用中退出（而不是从他们的社交帐户！）。我仍然拥有他们的社交访问令牌，但我销毁了另一个令牌我发给他们使用我的REST api 。现在，用户使用社交登录（例如Fb / Google）返回登录我的应用程序。我将如何重新验证这些用户？我知道我不需要用户再次提供权限，但我怎么知道他们是Fb / Google的合法用户，并且我的服务器端也有帐户？成功登录后，Fb / Google会向应用程序提供哪些内容，以便我可以发回服务器说：＆＃34;是的，这个用户是Fb / Google的合法社交用户。＆＃34;。在上述注册程序中，社交oauth提供者将提供授权代码。在这种情况下我会得到什么（后续登录）？

基本上，我需要找到一种方法来重新发出访问令牌到我的REST API，以便成功重新登录应用程序的FB / Google用户。

Answer 1

回答你的问题，

1. 上述过程是一个好习惯吗？

是的，这确实是一个很好的做法，为什么要问？您没有在移动端存储客户端Id / Secret，而您只是重定向到Oauth身份验证的社交提供者站点，并且服务器之间进行通信，这也被认为是安全的。

关于第三方提供商的访问令牌，除非您以后想要访问社交提供商的任何资源，否则您不必存储任何访问令牌，即一旦您通过身份验证，您就可以安全地丢弃其访问令牌和生成你自己的

关于第二个问题，

您不必担心，即一旦用户注销，您只需要撤销由您发出的accessToken。

关于Oauth流程，您只需重定向到社交提供商的oauth Flow（不用担心用户是否登录），社交提供商将负责处理，您将获得授权代码最后，你只需要像第一次那样处理它。

希望这能回答你的问题！