从Google / Facebook帐户重新validation用户
所以我需要创build一个REST API来为IOS应用程序提供function。 我们允许用户使用简单的帐户或Facebook / Googlelogin注册 。
最近我一直在阅读OAuth，并且我想我理解如何在我的情况下（当用户使用Facebook / Googlelogin时 ）在我的应用上注册一个帐户时使用OAuth的过程：
- 我向各种社交提供商（例如FB / Google）注册我的IOS应用程序。 我终于安全地存储在后端的客户端ID /客户端密钥。
- 现在，用户点击应用程序上的社交loginbutton，然后将用户redirect到社交网站login并授予我的应用程序使用他们的社交帐户的权限。
- 社交oauth提供商将用授权码将用户redirect回我的服务器。
- 一旦我的服务器有授权码，我将使用这个，客户端ID和秘密（或任何其他特定的证书需要）从社交oauth提供者检索访问令牌。
- 现在我有用户的访问令牌，并可以使用他们的社交资源一段时间（耶）。
- 一旦我有他们的社交访问令牌，然后我发出一个生成的访问令牌的应用程序使用请求时，我的REST API（应用程序将只与我的REST API从现在）沟通。
我的问题：
- 上述过程是一个好的做法吗？
- 比方说，用户从应用程序注销（而不是从他们的社交帐户！）。 我仍然有他们的社交访问令牌，但我摧毁了我发给他们使用我的REST API的另一个标记。 现在用户回来login到我的应用程序使用社交login（例如Fb /谷歌）。 我将如何重新validation这些用户？ 我知道我不需要用户再次提供权限，但是如何知道他们是Fb / Google的合法用户，并且在我的服务器端也有一个帐户？ 如果成功login，Fb / Google会提供回应用程序，以便我可以发送回我的服务器：“是的，这个用户是Fb / Google的合法社交用户。” 在上述注册程序中，社会福利提供者将提供授权码。 在这种情况下，我会得到什么（后续login）？
基本上， 我需要find一种方法来重新发布访问令牌到我的REST API，以成功地在应用程序的FB / Google用户中重新注册。
要回答你的问题，
- 上述过程是一个好的做法吗？
是的，这确实是一个很好的做法，你为什么要问？ 您不会将客户端Id / Secret存储在移动端，而只是将您redirect到Oauth身份validation的社交提供商站点，并且在服务器到服务器之间发生通信，这也被认为是安全的。
关于第三方提供商的访问令牌，除非您想在以后访问社交提供商的任何资源，您不必存储任何访问令牌，即一旦通过validation，您就可以放心地丢弃访问令牌并生成自己的访问令牌
对于第二个问题，
您不必担心，即一旦用户注销，您只需撤销您发出的accessToken。
对于Oauthstream程，您只需redirect到社交服务提供商的oauth Flow（而不用担心用户是否已login），社交服务提供商会照顾它，最终您将获得授权代码，你只需要像第一次那样处理它。
希望这回答你的问题！