目前,我必须为每项服务进行两次OAuth 2身份验证:一次作为iframe中自然身份验证的一部分,另一次是当我要求用户授予我访问此服务的权限时(出于API原因).
有没有办法简化这个过程?
解决方法 最先进的响应是完全修改您的应用程序.>你应该有1个SPA申请而不是iframe
>此应用程序将进行身份验证以获取OAuth2令牌
>然后,此应用程序将调用后端(访问多个后端,或访问调用后端的API管理层).
事情是,你可以有两个策略:
>在第一次认证时给予所有许可(范围)
>在第一次认证时提供较小范围,然后在需要时“重新认证”(实际上验证新范围)以获得新的访问令牌
当API想要调用另一个API时,您还有3个策略:
>您只需使用API接收的API调用服务的相同客户端令牌(无需人工交互)
>您的API从服务帐户生成令牌(使用ROPC身份验证方案),(无需人工交互). (API将是第二个API的客户端)
>您的身份提供者有一个端点来转换访问令牌:您的API可以为客户端提供访问令牌,授权服务器将使用您的API的clIEnt_ID对其进行转换.您将此令牌发送到2ndAPI(令牌将显示您的UI应用程序的主题,但客户端ID将是第一个API clIEntID)(不需要人工交互)
现在,如果您在同一个域上使用带有多个子应用程序的iframe(该域需要完全相同!),则可以通过本地存储共享相同的访问令牌. (安全不是一流的)
您可能需要在某个时间使用更大的范围列表进行身份验证,但这是您唯一的选择.您将模拟单个页面应用程序,但问题是您将具有可能不同的clIEnt_ID,具体取决于您进行身份验证的第一个应用程序.
编辑:多个授权服务器
从您的评论中,您有多个授权服务器.一种策略可能是要求用户进行身份验证,然后您的应用程序可以获得access_token和refresh_token.根据您的授权服务器,refresh_token可以在很长一段时间内被大量使用,因此,如果您将其存储在某个地方,则下次用户访问您的应用程序时,您的应用程序可以静默地从此刷新令牌获取access_token.然后,您的应用程序可以访问删除API,而无需用户进行更新的交互.当然,这意味着您必须尽可能安全地保存此令牌.
总结以上是内存溢出为你收集整理的iframe和api的OAuth 2身份验证全部内容,希望文章能够帮你解决iframe和api的OAuth 2身份验证所遇到的程序开发问题。
如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)