15 Go 鉴权（一）：鉴权机制概述

一、系统鉴权概述

在现代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 所使用的那个目录服务进行通信即可做到这一点。或者，我们可以在服务内部存储用户名和密码，但需要承担存在重复行为的风险。

注意：使用这种方法，服务器只知道客户端有用户名和密码。我们不知道这个信息是否来自我们期望的机器；它可能来自网络中的其他人。