[译] 认证 vs 授权

原文:Authentication vs Authorization

有许多实用并且具有哲学性的方法来讨论这两个术语的区别。但是这里确实有一些困惑,我想要从如今普遍用于构建应用的基于 token 的协议的“通常猜测”的角度去看待它。特别是我想要解析清楚 OAuth2 和 OpenID Connect 各自的适用场景。

首先看一下“正式”定义:

认证 是个人或者计算机程序为了获取信息而证实他们身份的过程。
授权 是许可个人或者实体权限从而在一个安全的环境使用资源的行为。通常与认证紧密相关。

认证

我的经验法则是,当应用请求 identity token 供它自己使用以提供个性化或者应用访问控制的特性时,那就是认证。或者从技术上来讲,请求到的 token 的受众是请求者本身,而且请求的应用能够解析和验证 token 以当中包含的信息。

[译] 认证 vs 授权

用于认证的典型协议有:Kerberos, WS-Federation, SAML2p, OpenID (Connect) 。得到的 token 常称为 identity token 。

授权

相反,当应用请求 token 供第三方而非自己使用的时候——比如,后台,属于授权存储区。这个 token 对于请求者是不透明的并且只在受众(也就是后台)的上下文中才有意义。后台可以解析并验证 token ,可以根据里面的内容实现访问控制的管理。

[译] 认证 vs 授权

用于授权的典型协议有:Kerberos, WS-Trust, OAuth2 。得到的 token 常称为 access token 。

但是——怎么使用 OAuth2 进行认证?

一些提供商建议使用 OAuth2 来完成登录——但这适合吗?当你进一步了解 OAuth2 的时候会发现它本身并不能提供认证服务,你可以看到这些提供商会使用一些自定义的扩展来完成这个工作。引用一下 Google 的文档(链接):

“这里所述的 Google 端点与 OpenID Connect 规范保持一致,目前,它还处于草案阶段。作为参考,OpenID Connect 规范与 OAuth 2.0 协议很相似。在规范完善的过程中,Google 端点将会不断进行更新。”

分享一些能够告诉你 OAuth2 认证骗局的文章,推荐阅读 Tim Bray 的 这篇 文章,OpenID Connect 规范 ,以及 这篇这篇 解释了为什么 OAuth2 本身是不够的。

上一篇:启动 zabbix-server 报错


下一篇:UIWebView体系结构(五)_UIWebViewScrollView和UIWebScrollView