需求背景

假设，你正在参与开发一个微服务。微服务通过 HTTP 协议暴露接口给其他系统调用，说直白点就是，其他系统通过 URL 来调用微服务的接口。有一天，你的 leader 找到你说，“为了保证接口调用的安全性，我们希望设计实现一个接口调用鉴权功能，只有经过认证之后的系统才能调用我们的接口，没有认证过的系统调用我们的接口会被拒绝。我希望由你来负责这个任务的开发，争取尽快上线。”

需求分析

1. 第一轮基础分析

对于如何做鉴权这样一个问题，最简单的解决方案就是，通过用户名加密码来做认证。我们给每个允许访问我们服务的调用方，派发一个应用名（或者叫应用 ID、AppID）和一个对应的密码（或者叫秘钥）。调用方每次进行接口请求的时候，都携带自己的 AppID 和密码。微服务在接收到接口调用请求之后，会解析出 AppID 和密码，跟存储在微服务端的 AppID 和密码进行比对。如果一致，说明认证成功，则允许接口调用请求；否则，就拒绝接口调用请求。

2. 第二轮分析优化

不过，这样的验证方式，每次都要明文传输密码。密码很容易被截获，是不安全的。那如果我们借助加密算法（比如 SHA），对密码进行加密之后，再传递到微服务端验证，是不是就可以了呢？实际上，这样也是不安全的，因为加密之后的密码及 AppID，照样可以被未认证系统（或者说黑客）截获，未认证系统可以携带这个加密之后的密码以及对应的 AppID，伪装成已认证系统来访问我们的接口。 这就是典型的“重放攻击” 。

提出问题，然后再解决问题，是一个非常好的迭代优化方法。对于这个问题，我们可以借助 OAuth 的验证思路来解决。调用方将请求接口的 URL 跟 AppID、密码拼接在一起，然后进行加密，生成一个 token。调用方在进行接口请求的的时候，将这个 token 及 AppID，随 URL 一块传递给微服务端。微服务端接收到这些数据之后，根据 AppID 从数据库中取出对应的密码，并通过同样的 token 生成算法，生成另外一个 token。用这个新生成的 token 跟调用方传递过来的 token 对比。如果一致，则允许接口调用请求；否则，就拒绝接口调用请求。

3. 第三轮分析优化

不过，这样的设计仍然存在重放攻击的风险，还是不够安全。每个 URL 拼接上 AppID、密码生成的 token 都是固定的。未认证系统截获 URL、token 和 AppID 之后，还是可以通过重放攻击的方式，伪装成认证系统，调用这个 URL 对应的接口。

为了解决这个问题，我们可以进一步优化 token 生成算法，引入一个随机变量，让每次接口请求生成的 token 都不一样。我们可以选择时间戳作为随机变量。原来的 token 是对 URL、AppID、密码三者进行加密生成的，现在我们将 URL、AppID、密码、时间戳四者进行加密来生成 token。调用方在进行接口请求的时候，将 token、AppID、时间戳，随 URL 一并传递给微服务端。

微服务端在收到这些数据之后，会验证当前时间戳跟传递过来的时间戳，是否在一定的时间窗口内（比如一分钟）。如果超过一分钟，则判定 token 过期，拒绝接口请求。如果没有超过一分钟，则说明 token 没有过期，就再通过同样的 token 生成算法，在服务端生成新的 token，与调用方传递过来的 token 比对，看是否一致。如果一致，则允许接口调用请求；否则，就拒绝接口调用请求。

4. 第四轮分析优化

不过，你可能会说，这样还是不够安全啊。未认证系统还是可以在这一分钟的 token 失效窗口内，通过截获请求、重放请求，来调用我们的接口啊！

说得没错。不过，攻与防之间，本来就没有绝对的安全。我们能做的就是，尽量提高攻击的成本。这个方案虽然还有漏洞，但是实现起来足够简单，而且不会过度影响接口本身的性能（比如响应时间）。所以，权衡安全性、开发成本、对系统性能的影响，这个方案算是比较折中、比较合理的了。

还有一个细节我们没有考虑到，那就是，如何在微服务端存储每个授权调用方的 AppID 和密码。当然，这个问题并不难。最容易想到的方案就是存储到数据库里。不过，开发像鉴权这样的非业务功能，最好不要与具体的第三方系统有过度的耦合。

针对 AppID 和密码的存储，我们最好能灵活地支持各种不同的存储方式，比如 本地配置文件、自研配置中心、数据库、Redis 等。我们不一定针对每种存储方式都去做代码实现，但起码要留有扩展点，保证系统有足够的灵活性和扩展性，能够在我们切换存储方式的时候，尽可能地减少代码的改动。

5. 最终确定需求

到此，需求已经足够细化和具体了。现在，我们按照鉴权的流程，对需求再重新描述一下。

• 调用方进行接口请求的时候，将 URL、AppID、密码、时间戳拼接在一起，通过加密算法生成 token，并且将 token、AppID、时间戳拼接在 URL 中，一并发送到微服务端。
• 微服务端在接收到调用方的接口请求之后，从请求中拆解出 token、AppID、时间戳。
• 微服务端首先检查传递过来的时间戳跟当前时间，是否在 token 失效时间窗口内。如果已经超过失效时间，那就算接口调用鉴权失败，拒绝接口调用请求。
• 如果 token 验证没有过期失效，微服务端再从自己的存储中，取出 AppID 对应的密码，通过同样的 token 生成算法，生成另外一个 token，与调用方传递过来的 token 进行匹配；如果一致，则鉴权成功，允许接口调用，否则就拒绝接口调用。

开发实现

1. 划分职责进而识别出有哪些类

首先，我们要做的是逐句阅读上面的需求描述，拆解成小的功能点，一条一条罗列下来。注意，拆解出来的每个功能点要尽可能的小。每个功能点只负责做一件很小的事情（专业叫法是“单一职责”）。下面是我逐句拆解上述需求描述之后，得到的功能点列表：

1. 把 URL、AppID、密码、时间戳拼接为一个字符串；
2. 对字符串通过加密算法加密生成 token；
3. 将 token、AppID、时间戳拼接到 URL 中，形成新的 URL；
4. 解析 URL，得到 token、AppID、时间戳等信息；
5. 从存储中取出 AppID 和对应的密码；
6. 根据时间戳判断 token 是否过期失效；
7. 验证两个 token 是否匹配；

从上面的功能列表中，我们发现，1、2、6、7 都是跟 token 有关，负责 token 的生成、验证；3、4 都是在处理 URL，负责 URL 的拼接、解析；5 是操作 AppID 和密码，负责从存储中读取 AppID 和密码。所以，我们可以粗略地得到三个核心的类：AuthToken、Url、CredentialStorage。AuthToken 负责实现 1、2、6、7 这四个操作；Url 负责 3、4 两个操作；CredentialStorage 负责 5 这个操作。

2. 定义类及其属性和方法

现在我们来看下，每个类都有哪些属性和方法。我们还是从功能点列表中挖掘。

AuthToken 类相关的功能点有四个：

• 把 URL、AppID、密码、时间戳拼接为一个字符串；
• 对字符串通过加密算法加密生成 token；
• 根据时间戳判断 token 是否过期失效；
• 验证两个 token 是否匹配。

根据功能点描述，识别出来 AuthToken 类的属性和方法，代码骨架如下：

public class AuthToken
{
    private const long DEFAULT_EXPIRED_TIME_INTERVAL = 1 * 60 * 1000;
    private string _token;
    private long _createTime;
    private long _expiredTimeInterval = DEFAULT_EXPIRED_TIME_INTERVAL;
​
    public AuthToken(string token, long createTime) : this(token, createTime, DEFAULT_EXPIRED_TIME_INTERVAL)
    {
​
    }
​
    public AuthToken(string token, long createTime, long expiredTimeInterval)
    {
        _token = token;
        _createTime = createTime;
        _expiredTimeInterval = expiredTimeInterval;
    }
​
    public static AuthToken BuildAuthToken(ApiRequest req, string password)
    {
        string srcStr = $"{req.BaseUrl}?AppID={req.AppId}&Timestamp={req.Timestamp}";
        string token = GenerateToken(srcStr, password);
        AuthToken authToken = new AuthToken(token, req.Timestamp);
        return authToken;
    }
​
    public string GetToken()
    {
        return _token;
    }
​
    public bool IsExpired()
    {
        if (_createTime > DateTime.Now.Ticks + _expiredTimeInterval)
        {
            return true;
        }
        return false;
    }
​
    public bool Match(AuthToken authToken)
    {
        if (_token.Equals(authToken.GetToken()))
        {
            return true;
        }
        return false;
    }
​
    public static string GenerateToken(string srcStr, string password)
    {
        //TODO
        //Shal(srcStr, password);
        return srcStr + password;
    }
}

从上面的代码中，我们可以发现这样三个小细节。

• 第一个细节： 并不是所有出现的名词都被定义为类的属性，比如 URL、AppID、密码、时间戳这几个名词，我们把它作为了方法的参数。
• 第二个细节： 我们还需要挖掘一些没有出现在功能点描述中属性，比如 createTime，expireTimeInterval，它们用在 IsExpired()方法中，用来判定 token 是否过期。
• 第三个细节： 我们还给 AuthToken 类添加了一个功能点描述中没有提到的方法 GetToken()。

第一个细节告诉我们，从业务模型上来说，不应该属于这个类的属性和方法，不应该被放到这个类里。比如 URL、AppID 这些信息，从业务模型上来说，不应该属于 AuthToken，所以我们不应该放到这个类中。

第二、第三个细节告诉我们，在设计类具有哪些属性和方法的时候，不能单纯地依赖当下的需求，还要分析这个类从业务模型上来讲，理应具有哪些属性和方法。这样可以一方面保证类定义的完整性，另一方面不仅为当下的需求还为未来的需求做些准备。

Url 类相关的功能点有两个：

• 将 token、AppID、时间戳拼接到 URL 中，形成新的 URL；
• 解析 URL，得到 token、AppID、时间戳等信息。

虽然需求描述中，我们都是以 URL 来代指接口请求，但是，接口请求并不一定是以 URL 的形式来表达，还有可能是 RPC 等其他形式。为了让这个类更加通用，命名更加贴切，我们接下来把它命名为 ApiRequest。下面根据功能点描述设计的 ApiRequest 类。

public class ApiRequest
{
    public ApiRequest(string baseUrl, string appId, long timestamp, string token)
    {
        BaseUrl = baseUrl;
        AppId = appId;
        Timestamp = timestamp;
        Token = token;
    }
​
    public string BaseUrl { get; set; }
    public string AppId { get; set; }
    public long Timestamp { get; set; }
    public string Token { get; set; }
​
    public static ApiRequest BuildFromUrl(string url)
    {
        ApiRequest req = new ApiRequest("xxx.com", "designpattern", DateTime.Now.Ticks, "IXIGIpJ9hdOBCyjStaDJ5Nom07g=");
        return req;
    }
}

CredentialStorage 类相关的功能点有一个：

CredentialStorage 类非常简单，为了做到抽象封装具体的存储方式，我们将 CredentialStorage 设计成了接口，基于接口而非具体的实现编程。

public interface ICredentialStorage
{
    string GetPasswordByAppId(string appId);
}

将类组装起来并提供执行入口

类定义好了，接下来我们要将所有的类组装在一起，提供一个执行入口。这个入口可能是一个 main() 函数，也可能是一组给外部用的 API 接口。通过这个入口，我们能触发整个代码跑起来。

接口鉴权并不是一个独立运行的系统，而是一个集成在系统上运行的组件，所以，我们封装所有的实现细节，设计了一个最顶层的 ApiAuthenticator 接口类，暴露一组给外部调用者使用的 API 接口，作为触发执行鉴权逻辑的入口。

public interface IApiAuthenticator
{
    void Auth(string url);
}
​
public class DefaultApiAuthenticator : IApiAuthenticator
{
    private ICredentialStorage _credentialStorage;
    public DefaultApiAuthenticator(ICredentialStorage credentialStorage) 
    {
        _credentialStorage = credentialStorage; 
    }
​
    public void Auth(string url)
    {
        ApiRequest apiRequest = ApiRequest.BuildFromUrl(url);
        AuthToken clientAuthToken = new AuthToken(apiRequest.Token, apiRequest.Timestamp);
​
        if (clientAuthToken.IsExpired())
        {
            throw new Exception("Token is expired.");
        }
        string password = _credentialStorage.GetPasswordByAppId(apiRequest.AppId);
        AuthToken serverAuthToken = AuthToken.BuildAuthToken(apiRequest, password);
        if (!serverAuthToken.Match(clientAuthToken))
        {
            throw new Exception("Token verfication failed.");
        }
    }
}