我正在使用IdentityServer为移动（本机）应用程序和网站构建OAuth 2.0服务器。我想知道我应该在移动应用程序和网站中使用的正确流程。
据我所知，＆＃34;隐含＆＃34;流程几乎是我在注册为外部API（例如Facebook）的开发人员时所获得的，当用户使用他的Facebook帐户登录我的网站时，他被称为Facebook登录页面，指导他使用令牌回到我的网站。这对我来说似乎很安全，因为auth服务器将用户引用回调网址（至少对于网站而言）。
到目前为止我实施的是资源所有者＆＃34; flow，使用client_id及其密码验证服务器的用户凭据。我看到的问题是client_id和密码存储在应用程序上（可以反向设计）或网站上的javascript代码。
我在这个post（What's the right OAuth 2.0 flow for a mobile app）上读到，最好在我的API上创建一个登录方法，我的API将与auth服务器通信（所以client_id和密码只存储在其上。）
我想知道像Facebook或Google这样的公司是如何做到这一点的。他们在网站上有自己的登录信息，他们为第三方开发人员提供API访问权限 - 这会阻止开发人员针对Facebook登录对用户进行一些身份验证并使用他们的API而不受限制？
答案 0 :(得分：0)
我会使用Implicit流程，因为正如您所提到的，您无法在应用程序中保护您的密码安全。
由于您的后端是无状态的，因此您需要为每个请求发送一个令牌（ID令牌或访问令牌）。后端处理的流（例如Auth Code grant）不适合无状态API。
如果您只想对用户进行身份验证，我猜您的后端自己处理访问权限，并且不依赖于访问令牌范围。然后我将使用OpenID Connect（OAuth2扩展） - 仅请求openid范围来获取ID令牌。 ID令牌保证用户的身份，后端不必在OAuth2服务器上验证它的有效性。
如果要在OAuth2服务器上为用户配置权限，您的前端应用程序将需要获取访问令牌。然后，后端可以读取访问令牌的范围。
在前端应用程序中保留令牌时，他们需要观察令牌有效期并在当前的令牌到期之前请求新令牌。您可以在/auth端点（带prompt=none网址参数）进行此操作。有关详细信息，请查看OpenID Connect Session Management。
使用OAuth2时，请务必记住它是关于权限委派的。以Google为例，他们提供依赖于由其发布的访问令牌的OAuth2服务器和应用程序。因此，如果第三方应用程序想要代表用户使用Google Plus，则应用程序必须请求用户授予其访问Google Plus的权限（访问令牌范围）。用户可以在同意页面查看请求的范围列表，并且不允许应用程序执行任何其他操作。用户可以考虑他对应用程序的信任程度。有关详细信息，请参阅OAuth2 spec。