颠覆认知！为什么“发 Token”其实是「授权」而不是「认证」？-平芜编程栈

🤯 颠覆认知！为什么“发 Token”其实是「授权」而不是「认证」？

👋嗨，开发者们！

在做登录功能时，我们经常听到这两个词：Authentication（认证）和Authorization（授权）。

很多人（包括曾经的我）都潜意识地认为：“登录就是认证，Token 是登录成功的产物，所以发 Token 也是认证的一部分。”

🛑打住！这个理解其实是不准确的。

今天我们来聊聊一个架构设计中的冷知识：为什么颁发 Token（令牌）这个动作，在本质上属于「授权」？🚀

🕵️‍♂️ 一、认证 vs 授权：傻傻分不清楚？

首先，我们用一个“去公司大楼上班”的例子来彻底厘清这两个概念：

1️⃣ 认证 (Authentication) = 验明正身 🆔

场景：你走到大门口，保安大叔拦住你：“你谁啊？”
动作：你掏出身份证，或者刷脸。保安核对照片和本人，确认你是“张三”。
核心问题：你是谁？(Who are you?)
代码对应：checkPassword(username, password)

2️⃣ 授权 (Authorization) = 赋予权力 💳

场景：保安确认你是张三后，但他不能让你直接进去。他拿出一张门禁卡，在读写器上刷了一下（写入权限：可进 1-5 层），然后把卡递给你。
动作：发放门禁卡。
核心问题：你能干什么？(What can you do?)
代码对应：JwtUtil.createToken(userId, role)

💡看出来了吗？
核对身份证是“认证”，但把门禁卡（Token）递给你的那一刻，其实是在进行“授权”。因为那张卡代表了你在大楼里的权力。

🛠 二、铁证如山：看看标准协议怎么说

如果你还觉得那是咬文嚼字，我们来看看国际标准协议OAuth 2.0是怎么定义的。

在 OAuth 2.0 中，负责生成和发放 Token 的那个服务，官方名称叫：

👉Authorization Server（授权服务器）

它不叫Authentication Server，也不叫Login Server。

为什么？
因为 Token（特别是 JWT）的本质就是一份“授权书”。
当你把 Token 发给客户端时，你的潜台词是：

📢“我授权持有这个 Token 的人，代表用户 ID: 10086，在未来 2 小时内，访问我的资源服务器。”

💻 三、代码视角的“解剖”

在我们的 Java / Go / Node.js 代码中，一个所谓的login接口，其实通常原子化地执行了两个步骤：

publicStringlogin(Stringusername,Stringpassword){// 🔥 步骤 1：认证 (Authentication)// 这一步只负责判断真假，不产生 TokenUseruser=userRepo.findByName(username);if(!passwordEncoder.matches(password,user.getPassword())){thrownewAuthenticationException("密码错误！");}// ✨ 步骤 2：授权 (Authorization)// 这一步负责打包权限，生成令牌// 这里的动作是：系统授予了用户访问 API 的凭证Stringtoken=JwtUtil.createToken(user.getId(),user.getRole());returntoken;}

步骤 1结束时，系统只是知道了“你是张三”。
步骤 2结束时，系统才赋予了张三“通行权”。

🧠 四、为什么区分这个很重要？

你可能会问：“反正都是写在一个接口里，分那么细有啥用？” 🤔

在微服务和中台架构中，这个区别至关重要：

架构解耦🧩
- 统一认证中心 (IAM)可能只负责验密码（认证）。
- 而业务系统可能需要根据认证结果，自己发放特定业务的 Token（授权）。
理解 OIDC🌐
- OIDC (OpenID Connect)协议之所以存在，就是因为 OAuth 2.0 只管授权（发 Token），不管身份。OIDC 补上了 ID Token，才把“认证”和“授权”完美结合起来。
安全模型🛡️
- 理解了 Token 是授权，你就明白了为什么Token 泄露 = 权限被盗。因为捡到门禁卡的人，拥有和你一样的权力！