基于OAuth2的单点登录
基于OAuth2的单点登录
提问于 2019-02-14 12:34:13
开发了基于OAuth2的单点登录系统。
我有3项服务：
- SSO标识提供程序，包含用户和OAuth2服务器- http://sso.idp.loc
- 在角- http://sso.sp-angular.loc上具有前端部分的SSO服务提供商
- SSO服务提供商(休闲网站)- http://sso.sp-web.loc
服务提供者检查由标识提供程序发出的每个请求访问令牌。
下一个机制是：
- 转到任何序列化提供程序并按下登录。
- 重定向到sso.idp.loc/login_check以检查凭据(从cookie)。
- 如果没有授权-转到sso.idp.loc/登录。
- 在为身份提供程序记录内集cookie并在get参数中使用这些cookie重定向到目标服务提供者之后。
- 为服务提供者设置get参数中的新cookie，并将其重定向到目标路径。
- 如果突然在服务提供者上身份验证失败，请转到sso.idp.loc/login_check与目标路径。
Cookie包含oauth访问和令牌。
在访问令牌有效的情况下，一切都很好。一旦访问令牌过期，服务prodider将转到sso.idp.loc/login_check，然后再次检查访问令牌，然后尝试使用刷新令牌获得新的令牌。如果成功，那么新的creadentials就会被设置为sso.idp.loc和服务提供者。假设是在sso.sp-web.loc上发生的。
这里我有几个问题：
- 然后另一个服务提供者sso.sp-angular.loc不知道凭据被更改，下一个请求将重定向到sso.idp.loc/login_check (可以通过第二次发送请求来排序)。
- 当用户在sso.sp-web.loc和令牌上编辑表单时，提交将失败。
- 令牌过期时如何管理ajax调用？
应该考虑一个事实，即访问令牌可以在任何时候更改。
可能我的系统出了什么问题。我很乐意在此提出任何解决办法。
回答 2
Stack Overflow用户
回答已采纳
发布于 2019-02-15 08:23:10
我认为您的SSO概念是有缺陷的-您不应该共享相同的令牌。每个客户端(应用程序)的令牌应该是不同的。OAuth2 SSO通常以以下方式实现( OAuth2 RFC不包括该实现)：
- 应用程序"App1“通过将用户浏览器重定向到授权服务器(
/auth端点)来请求令牌。 - 授权服务器将会话cookie设置为浏览器，并保存有关哪个用户在该会话中进行身份验证的信息。cookie仅对授权服务器请求有效。
- 当另一个应用程序"App2“请求令牌时，浏览器将会话cookie与
/auth端点请求一起发送。授权服务器解析会话。会话已经过身份验证，因此授权服务器可能决定不立即请求凭据并释放新的令牌(或auth代码)。
Stack Overflow用户
发布于 2019-02-14 16:47:43
您似乎已经实现了隐式授予类型的OAuth 2.0。那很不安全。理想情况下，您应该在资源服务器(您所指的服务提供者)端实现授权代码授予类型并维护客户端机密。我建议你阅读答案here和here。
现在让我们回答以下问题：
- 如果正确设置了cookie的域属性，则第一个资源服务器设置的cookie也应该对第二个服务器可用。
- 当用户编辑表单和令牌过期时，资源服务器中的api过滤器可以检测到过期的令牌并将401响应代码返回给客户端。在接收401时，客户端或浏览器可以在服务器中进行另一个api调用以更新访问令牌。api将从cookie中获取刷新令牌，并使用客户端秘密和刷新令牌调用授权服务器以获得新的访问令牌。如果刷新tiken未过期，授权服务器将返回一对新的访问和刷新令牌，这些访问和刷新令牌将返回给浏览器和cookie集。浏览器现在将使用新的访问令牌再次调用表单submit api。所有这些都将无缝地发生在用户身上。只有在刷新令牌过期时才会发生完全故障。
- 与2中提到的方法相同。
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/54690523
复制相关文章
相似问题
腾讯云开发者
