想象一下以下常见情况。我有一个单页Web应用程序（SPA），它使用我在后端编写的RESTful API接收所有数据。
这些API也完全可以用于第三方。我的单页应用程序是使用API的数百万种应用程序中的另一种。在后台维护会话是为了进行身份验证和缓存。该会话通过具有会话ID的cookie持续。
要使用API，用户必须进行身份验证。我需要为我的应用程序支持大型SSO方法（OIDC / OAUTH2）。显然，我的API需要被Dell Boomi或plain ol'SSIS之类的集成软件使用。
现在，让我们谈谈身份验证和授权流程。经过数天的阅读，我了解了关于OAuth2和OpenID的所有内容，我想象以下工作流程。 myapp.com配置为通过Facebook（任意）进行SSO：
GET /customer/1> [API服务器] Dunno you, chump. 302 redirect here, plz.> [浏览器]
https://www.facebook.com/oauth/login?client_id=abcdef&state=12345 Username: lintlicker, password: iluvcats123> [Facebook] Yup, you're someone. 302 redirect here, plz.> [浏览器]
https://www.myapp.com/oauth/imback?code=a1b2c3d&state=12345 json of the stuff from the url> [API服务器] Here's a code and client-id and client-secret> [Facebook] Here's a token to run Facebook APIs for this user ................................ 但是，等等。我不想运行Facebook API。我只想使用Facebook进行身份验证，然后运行我的应用程序的API ...已经看到我误解了OAuth和OIDC。
好的，所以Facebook是使用OpenID的身份验证者。但是OAuth可以在我的API的外部使用吗？
我的API服务器基本上应该将来自浏览器/请求者的OAuth请求转发给身份提供者是谁吗？然后，我发送回一个在一个小时内到期的访问令牌，而不是一个cookie，而不是cookie中的会话ID。然后浏览器负责重新令牌吗？
这是否意味着浏览器或请求者具有客户端密码？明显不是。那么那是否意味着我必须使用/支持已贬值的隐式授予方法？
这里有什么好的架构？
答案 0 :(得分：0)
通过使用SSO，您的目标似乎可以提供社交登录行为。为此，您无需依赖Facebook发行的令牌。您可以做的是从ID令牌中获取用户数据，或者通过调用公开身份提供者的API（例如：Facebook）的用户信息来获取用户数据，并将其存储在后端之一中。从那时起，您就可以通过自己的令牌或会话来维护身份验证状态。
关于其他集成（API到API），对于那些集成，您的后端可以在成功完成OAuth流（例如：-客户端证书授予）后发布令牌。并且，如果这种集成带有第三方令牌（例如：Facebook），则您的后端可以允许令牌交换（如果需要，还可以添加用户注册，注册）。
上述方法的缺点是后端需要处理这些请求。如果可能的话，我建议嵌入一个轻量级的身份提供程序。这应该使所有东西都开箱即用。