<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>AK/SK - tag - 沐木</title><link>https://oldletter.cn/tags/ak/sk/</link><description>AK/SK - tag - 沐木</description><generator>Hugo -- gohugo.io</generator><language>zh-cn</language><lastBuildDate>Wed, 22 Apr 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://oldletter.cn/tags/ak/sk/" rel="self" type="application/rss+xml"/><item><title>数据开放平台架构设计（三）：鉴权与访问控制</title><link>https://oldletter.cn/posts/dp-03-auth-and-control/</link><pubDate>Wed, 22 Apr 2026 00:00:00 +0000</pubDate><author>mumu</author><guid>https://oldletter.cn/posts/dp-03-auth-and-control/</guid><description><![CDATA[<blockquote>
<p><strong>上一篇：</strong> <a href="/posts/dp-02-sql-to-api/" rel="">数据开放平台（二）：SQL 转 API 引擎</a></p></blockquote>
<p>数据开放平台把数据变成 API 给外部调用，安全问题是第一位的。谁都能调不行，调了不该看的字段也不行，更不能让某个调用方把数据库连接池打满。</p>
<p>这一篇聊三个问题：<strong>怎么认证调用方身份</strong>、<strong>怎么隔离不同租户的数据</strong>、<strong>怎么控制调用频率</strong>。</p>
<hr>
<h2 id="一aksk-签名认证">一、AK/SK 签名认证</h2>
<p>认证方案有很多种，为什么选 AK/SK？因为数据开放平台的调用方通常是<strong>服务端应用</strong>，不是浏览器用户。服务端对服务端的认证，AK/SK 是更成熟的方案，AWS、阿里云、腾讯云的开放 API 全用这个。</p>
<h3 id="核心概念">核心概念</h3>
<ul>
<li><strong>Access Key (AK)</strong>：调用方的身份标识，公开的，放在请求头里</li>
<li><strong>Secret Key (SK)</strong>：签名密钥，保密的，不在网络上传输</li>
<li><strong>签名 (Signature)</strong>：用 SK 对请求内容做 HMAC-SHA256，服务端验签</li>
</ul>
<p>为什么 SK 不直接传？因为网络传输可能被中间人截获。签名的好处是：即使签名被截获，攻击者也无法反推出 SK，而且签名是和请求内容绑定的，换个请求签名就失效了。</p>
<h3 id="签名流程">签名流程</h3>
<p>AK/SK 认证的关键是两端对同一份规范化请求做签名，服务端不接收明文 SK：</p>
<div class="mermaid" id="id-3" data-mermaid-definition="c2VxdWVuY2VEaWFncmFtCiAgICAgICAgICAgICAgICAgICAgcGFydGljaXBhbnQgU0RLIGFzIOiwg&#43;eUqOaWuSBTREsKICAgICAgICAgICAgICAgICAgICBwYXJ0aWNpcGFudCBHVyBhcyBBUEkg572R5YWzCiAgICAgICAgICAgICAgICAgICAgcGFydGljaXBhbnQgQXV0aCBhcyDpibTmnYMgSGFuZGxlcgogICAgICAgICAgICAgICAgICAgIHBhcnRpY2lwYW50IFN0b3JlIGFzIOWHreaNruWtmOWCqAogICAgICAgICAgICAgICAgICAgIHBhcnRpY2lwYW50IEN0eCBhcyDor7fmsYLkuIrkuIvmlocKICAgICAgICAgICAgICAgICAgICBTREstPj5TREs6IOinhOiMg&#43;WMluaWueazleOAgei3r&#43;W&#43;hOOAgeWPguaVsOOAgeaXtumXtOaIs&#43;OAgU5vbmNlCiAgICAgICAgICAgICAgICAgICAgU0RLLT4&#43;U0RLOiDkvb/nlKggU0sg6K6h566XIEhNQUMKICAgICAgICAgICAgICAgICAgICBTREstPj5HVzog5pC65bimIEFL44CB562&#43;5ZCN44CB5pe26Ze05oiz44CBTm9uY2UKICAgICAgICAgICAgICAgICAgICBHVy0&#43;PkF1dGg6IOmAj&#43;S8oOiupOivgeWktAogICAgICAgICAgICAgICAgICAgIEF1dGgtPj5TdG9yZTog55SoIEFLIOafpeivoiBTSyDmkZjopoHmiJblr4bpkqXmnZDmlpkKICAgICAgICAgICAgICAgICAgICBTdG9yZS0tPj5BdXRoOiDov5Tlm57osIPnlKjmlrnkuI7np5/miLfkv6Hmga8KICAgICAgICAgICAgICAgICAgICBBdXRoLT4&#43;QXV0aDog5qCh6aqM5pe26Ze056qX5Y&#43;j5LiOIE5vbmNlCiAgICAgICAgICAgICAgICAgICAgQXV0aC0&#43;PkF1dGg6IOmHjeeul&#43;etvuWQjeW5tuavlOi&#43;gwogICAgICAgICAgICAgICAgICAgIEF1dGgtPj5DdHg6IOWGmeWFpeW6lOeUqOOAgeenn&#43;aIt&#43;OAgeadg&#43;mZkOiMg&#43;WbtA==">sequenceDiagram
                    participant SDK as 调用方 SDK
                    participant GW as API 网关
                    participant Auth as 鉴权 Handler
                    participant Store as 凭据存储
                    participant Ctx as 请求上下文
                    SDK-&gt;&gt;SDK: 规范化方法、路径、参数、时间戳、Nonce
                    SDK-&gt;&gt;SDK: 使用 SK 计算 HMAC
                    SDK-&gt;&gt;GW: 携带 AK、签名、时间戳、Nonce
                    GW-&gt;&gt;Auth: 透传认证头
                    Auth-&gt;&gt;Store: 用 AK 查询 SK 摘要或密钥材料
                    Store--&gt;&gt;Auth: 返回调用方与租户信息
                    Auth-&gt;&gt;Auth: 校验时间窗口与 Nonce
                    Auth-&gt;&gt;Auth: 重算签名并比较
                    Auth-&gt;&gt;Ctx: 写入应用、租户、权限范围</div><p>调用方发起请求时：</p>]]></description></item><item><title>API 鉴权实战（一）：AK/SK、API Key、RBAC 与统一认证授权架构设计</title><link>https://oldletter.cn/posts/api-auth-01-aksk-rbac/</link><pubDate>Tue, 10 Sep 2024 00:00:00 +0000</pubDate><author>mumu</author><guid>https://oldletter.cn/posts/api-auth-01-aksk-rbac/</guid><description><![CDATA[<blockquote>
<p>作者：林 | 系列：API 鉴权实战 | 适合读者：Java 后端/架构师</p></blockquote>
<blockquote>
<p>本文代码使用 Lombok 简化 POJO，所有 getter/setter/builder 均由 Lombok 自动生成。</p></blockquote>
<div class="code-block code-line-numbers open" style="counter-reset: code-block 0">
    <div class="code-header language-xml">
        <span class="code-title"><i class="arrow fas fa-angle-right" aria-hidden="true"></i></span>
        <span class="ellipses"><i class="fas fa-ellipsis-h" aria-hidden="true"></i></span>
        <span class="copy" title=""><i class="far fa-copy" aria-hidden="true"></i></span>
    </div><div class="highlight"><pre tabindex="0" class="chroma"><code class="language-xml" data-lang="xml"><span class="line"><span class="cl"><span class="c">&lt;!-- pom.xml --&gt;</span>
</span></span><span class="line"><span class="cl"><span class="nt">&lt;dependency&gt;</span>
</span></span><span class="line"><span class="cl">    <span class="nt">&lt;groupId&gt;</span>org.projectlombok<span class="nt">&lt;/groupId&gt;</span>
</span></span><span class="line"><span class="cl">    <span class="nt">&lt;artifactId&gt;</span>lombok<span class="nt">&lt;/artifactId&gt;</span>
</span></span><span class="line"><span class="cl">    <span class="nt">&lt;scope&gt;</span>provided<span class="nt">&lt;/scope&gt;</span>
</span></span><span class="line"><span class="cl"><span class="nt">&lt;/dependency&gt;</span></span></span></code></pre></div></div>
<hr>
<h2 id="一背景为什么要做-api-鉴权">一、背景：为什么要做 API 鉴权</h2>
<p>对外暴露 API 时，两个核心问题绕不开：</p>
<ol>
<li><strong>调用方是谁？</strong>（认证，Authentication）</li>
<li><strong>他能做什么？</strong>（授权，Authorization）</li>
</ol>
<p>简单的内部系统可能用一个 API Key 就够了。但当系统开始支持多租户、第三方接入、AI 开放平台、文件上传、额度控制时，单一的鉴权方式撑不住。你需要一套完整的体系：从密钥管理到权限判断，从缓存设计到上下文传递。</p>
<p>本文从更基础的 API Key 讲起，逐步构建到 PDP 策略决策点，把认证授权的全链路打通。</p>
<hr>
<h2 id="二五种鉴权方式详解">二、五种鉴权方式详解</h2>
<h3 id="21-api-key">2.1 API Key</h3>
<p><strong>原理：</strong> 给每个调用方分配一个唯一的密钥字符串，请求时放在 Header 里，服务端查库校验。</p>
<p><strong>适用场景：</strong> 内部服务间调用、快速原型、低安全要求的公开 API。</p>
<p><strong>不适用场景：</strong> 对外开放的 API，API Key 是静态的，明文传输，一旦被截获攻击者就能冒充调用方。</p>]]></description></item></channel></rss>