- 当您访问您的站点时 - 对 http://localhost:4200 的 GET 调用 -> 本地网络服务器以 Angular 的 index.html 响应,然后捆绑的 js 执行并决定显示什么。使用您的身份验证机制捆绑 Angular 的 js 代码实现身份验证丢失,根据您在那里编写的后备计划,它重定向到 IDP(在您向服务器询问 IDP 的 url 之间)。(所有这些过程都发生在浏览器中。)
- 点击 auth - GET 调用 IDP 的登录名(现在您要离开 Angular 应用程序并显示 IDP 的前端)。发布您的凭据并登录(IDP 的前端调用 IDP 的后端并登录)。(所有这些都发生在您的浏览器中)然后
- (在这里,我猜您注册了一个属于您的后端的 post auth 重定向 url。)这会对您的后端进行 GET 调用。如果您的休息控制器响应某些内容,那么它将显示在您的浏览器中。
现在...
谁实际登录?用户
谁代表你的用户?前端 -> 角度
后台登录了吗?不
后端代表任何人吗?不
每个用户的后端。任何授权的 api 调用都意味着后端将临时代表该用户(在 auth 中指定的内容)。当 API 调用结束时,后端停止动作。
纠正您的流程。您需要在登录后重定向到您的前端。因此,当您向 IDP 注册您的应用程序时,重定向 url 必须是您的前端路由。此 url 可以是在您的 Angular 应用程序中具有路由的组件。类似 http://localhost:4200/login
对于 OAuth SAML 流程,我们会收到一个临时的 - 在前端仅使用一次身份验证码。我们会将其提供给后端并要求将其转换为访问令牌、id 令牌、刷新令牌等。然后取决于您,您可以查看 id 令牌(解析 JWT)并将新的用户信息再次打包到 JWT 中。您可以通过将其作为对传递 authcode 的 api 调用的响应将其返回给 angular。
但是……近年来很多事情都发生了变化。
现在 SPA 被认为是一个应用程序,但却是一个不安全的应用程序(笑)
所以有一个最佳实践指南:https ://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-13
简短答案:从 IDP 重定向到您的 Angular 应用程序,而不是您的后端
学习更大的 OAuth 2.0 总是一个好主意。这将涵盖 SAML 流程 + 很多其他内容。有了它,您也可以了解其他系统中的 SAML 流实现。这是一种痛苦,但你被社区所覆盖。https://github.com/manfredsteyer/angular-oauth2-oidc确实是 Angular 的救星。