我正在使用微服务架构构建一个新的应用程序平台,但我一直在阅读很多关于要使用的不同类型的身份验证/授权的内容。
我正在适应 OAuth2/OpenID Connect,但只是为了确保我的假设是正确的。
我想知道我的流程是否适合处理我的应用程序的身份验证/授权。其次,对于我信任的应用程序,如何防止 OAuth 征求用户同意?
我正在使用微服务架构构建一个新的应用程序平台,但我一直在阅读很多关于要使用的不同类型的身份验证/授权的内容。
我正在适应 OAuth2/OpenID Connect,但只是为了确保我的假设是正确的。
我想知道我的流程是否适合处理我的应用程序的身份验证/授权。其次,对于我信任的应用程序,如何防止 OAuth 征求用户同意?
就协议/标准而言,为您所描述的系统使用 OAuth 2.0 和 OpenID Connect 是正确的决定。它们正在积极使用中,拥有大量库和第三方提供商的支持,并且它们的设计还考虑到了当今系统表现出的对 HTTP 的严重依赖。
在为每个应用程序选择正确的流程方面,该决定不受被视为第三方或受信任应用程序的应用程序的影响;它更多的是关于应用程序的部署特性,以及应用程序是否想要代表最终用户或代表应用程序本身访问资源。
检查Auth0 - 我应该使用哪个 OAuth 2.0 流程?很好地说明了这个决策过程。
第三方应用程序和受信任应用程序之间的区别由身份提供者/授权服务器自行决定。这通常是受支持的,因此如果应用程序受信任,则不会向最终用户明确征求同意;在这些情况下,将应用程序标记为跳过最终用户同意被视为一个管理步骤,在该步骤中,有人单方面地以行政方式决定授予此应用程序的同意,因此没有必要向最终用户征求同意。
如果您确实决定支持某些应用程序的管理同意,请记住,如果这些应用程序的特性不允许它们成为机密客户端(支持安全机制来验证客户端应用程序本身)或有其他方式来确保客户端身份然后恶意应用程序可能会尝试伪造受信任的应用程序以跳过用户同意步骤。