一、系统鉴权概述
在现代web开发中,系统鉴权服务已是基本标配模块,有些开发框架甚至内置了鉴权模块的实现,或者提供一些鉴权的工具类,然而鉴权的方式也分为多种,了解各种鉴权方式的特点及使用场景可以帮助我们构建更健壮的web系统。以下列出四种常见的鉴权方式,我们来认识一下:
- HTTP Basic Authentication
- Session-Cookie机制
- Token令牌机制
- OAuth2.0授权机制
二、鉴权方式简析
1.HTTP Basic Authentication
HTTP 基本身份验证,允许客户端在标准的 HTTP 头中发送用户名和密码。服务端可以验证这些信息,并确认客户端是否有权访问服务。这样做的好处在于,这是一种非常容易理解且得到广泛支持的协议。问题在于,通过 HTTP 有很高的风险,因为用户名和密码并没有以安全的方式发送。任何中间方都可以看到 HTTP 头的信息并读取里面的数据。因此,HTTP 基本身份验证通常应该通过 HTTPS 进行通信。
当使用 HTTPS 时,客户端获得强有力的保证,它所通信的服务端就是客户端想要通信的服务端。它给予我们额外的保护,避免人们窃听客户端和服务端之间的通信,或篡改有效负载。
服务端需要管理自己的SSL证书,当需要管理多台机器时会出现问题。一些组织自己承担签发证书的过程,这是一个额外的行政和运营负担。管理这方面的自动化工具远不够成熟,使用它们后你会发现,需要自己处理的事情就不止证书签发了。自签名证书不容易撤销,因此需要对灾难情景有更多的考虑。看看你是否能够避免自签名,以避开所有的这些工作。
SSL 之上的流量不能被反向代理服务器(比如 Varnish 或 Squid)所缓存,这是使用 HTTPS 的另一个缺点。这意味着,如果你需要缓存信息,就不得不在服务端或客户端内部实现。你可以在负载均衡中把 Https 的请求转成 Http 的请求,然后在负载均衡之后就可以使用缓存了。
还需要考虑,如果我们已经在使用现成的 SSO 方案(比如包含用户名密码信息的 SAML),该怎么办。我们想要基本身份验证使用同一套认证信息,然后在同一个进程里颁发和撤销吗?让服务与实现 SSO 所使用的那个目录服务进行通信即可做到这一点。或者,我们可以在服务内部存储用户名和密码,但需要承担存在重复行为的风险。
注意:使用这种方法,服务器只知道客户端有用户名和密码。我们不知道这个信息是否来自我们期望的机器;它可能来自网络中的其他人。