对于客户端编写非基于浏览器的非交互式应用程序的 REST API,如果 OAuth2 是要遵循的身份验证机制,那么我们将使用客户端凭据授予类型进行身份验证。这会是正确的选择吗?如果是这样,它比其他一些身份验证机制(如 Http 基本/摘要或基于证书的相互身份验证)更好吗?
带有客户端凭据的 OAuth2 与其他身份验证机制
信息安全
验证
oauth
休息
2021-08-19 11:00:46
1个回答
OAuth是一种授权协议,而不是一种身份验证协议。它的作用不是告诉你谁在电话的另一端,而是告诉你那个人能做什么。碰巧 OAuth 可以被滥用到身份验证系统中:这称为OpenID Connect。这个想法是为了给你授权信息(客户端是否允许这样做或那样?),OAuth 服务器必须首先确定客户端的身份(我们在说谁?);OpenID Connect 是关于重用该内部身份验证协议(“如果 OAuth 服务器授予访问权限,则特别是 OAuth 服务器对客户端进行身份验证,并且我们相信 OAuth 服务器使用的协议,无论它是什么”)。
如果您不相信 OAuth 服务器对客户端进行身份验证的方式,那么您可以使用其他身份验证方法,例如密码或客户端证书。在这种情况下,您的服务器进行身份验证,然后与 OAuth 服务器对话:“我有 Bob 在线,他可以做什么?”。
然后问题归结为:OAuth 服务器中的身份验证层是否适合您的情况?这由您决定。如果您决定自己进行身份验证,那么有几种具有不同特征的方法。哪个最好取决于上下文;只能以一般的方式发表一些评论:
- 无论您做什么,都使用 SSL。这对于确保您执行的身份验证和授权以不可更改的方式真正适用于客户端随后发送给您的任何请求是必要的。
- 既然你使用 SSL,就不要做 HTTP 摘要;改用 HTTP 基本。SSL 提供了比 HTTP 摘要提供的更好的保护(与 HTTP 基本相比);并且 HTTP 摘要与正确的密码服务器端存储机制 (bcrypt...) 不兼容。
- 客户端证书对用户来说更复杂,并且主要在身份验证和身份管理由单独的实体完成时才有意义。如果您只想为您的服务器验证您的用户,那么证书是多余的,可能不是一个好主意。
其它你可能感兴趣的问题