基于RESTful / OIDC的OAuth2 API认证与单点登录

Question

想象一下下面的常见场景。我有一个单页web应用程序(SPA)，它使用我在后端编写的RESTful API接收它的所有数据。

这些API也适用于第三方，就像现在一样。我的单页应用程序只是使用API的数百万人中的又一个。在后台维护会话，以利于身份验证和缓存。会话通过带有会话id的cookie持续存在。

要使用这些API，用户必须进行身份验证。我需要支持我的应用程序的大SSO方法(OIDC/OAUTH2)。很明显，我的API需要通过一个集成软件来使用，比如Dell或者简单的SSIS。

现在..。让我们来谈谈身份验证和授权流程。在阅读了OAuth2和OpenID上的所有内容之后，我设想了下面的工作流程。myapp.com通过Facebook配置为SSO (任意)：

1. 网络浏览器：GET /customer/1 > API
2. API：Dunno you, chump. 302 redirect here, plz. > Browser
3. 浏览器：Username: lintlicker, password: iluvcats123 > Facebook
4. Facebook：Yup, you're someone. 302 redirect here, plz. > Browser
5. 网络浏览器：json of the stuff from the url > API
6. API：Here's a code and client-id and client-secret > Facebook
7. 脸书：Here's a token to run Facebook APIs for this user................................

但是等等。我不想运行Facebook。我只想用Facebook认证然后运行我的应用程序的API..。您已经可以看到，我误解了OAuth与OIDC的区别。

好的，那么Facebook就是使用OpenID的认证者。但是，用于外部使用我的API的OAuth呢？

我的API服务器是否应该将OAuth请求从browser/ requestor转发给身份提供者？然后，我不再使用cookie中的会话id，而是返回一个在一个小时内到期的访问令牌，以及一个刷新令牌？那么浏览器负责更新令牌？

这是否意味着浏览器或请求者具有客户端秘密？显然不是。那么，这是否意味着我必须使用/支持折旧的隐式赠与法？

这里的好建筑是什么？

Answer 1

通过使用SSO，您的目标似乎提供了社交登录行为。为此，您不需要依赖Facebook发布的令牌。您可以做的是从ID令牌中获取用户数据，或者通过调用用户信息，公开身份提供者的API (例如：- Facebook)，并将它们存储在一个后端中。从此以后，您可以通过自己的令牌或会话来维护身份验证状态。

关于其他集成(API to API)，对于这些集成，您的后端可以在成功完成OAuth流(例如：- client凭据授予)时发出令牌。如果这种集成带有第三方令牌(例如：- Facebook)，那么后端可以允许令牌交换(如果需要的话，还可以允许用户登录注册)。

上述方法的缺点是后端需要处理这些请求。如果可能的话，我建议嵌入一个轻量级的身份提供者。这应该能把所有的东西都拿出来！