北京
如果问十个初级开发者OAuth 2.0是怎么工作的，九个人会脱口而出“授权服务器”“Bearer令牌”“PKCE”“隐式授权”这些术语，还能画出一张六条箭头来回穿梭的时序图。
但换个问法——为什么某个特定的HTTP请求必须存在？去掉它到底会坏在哪？多数人说不清楚。
问题出在教法上。大多数教程一上来就堆定义、画时序图，却从不讲协议最初是被什么工程难题逼出来的。
这篇指南换个路径：从一个真实的工程困境出发，一步步走到协议方案。等最后用Spring Boot写代码时，每个参数、重定向、令牌为什么存在，你会觉得理所当然。
假设你正在开发TravelBuddy，一个帮用户规划行程的应用。它有个功能：自动检测日程冲突，然后把行程直接塞进用户的Google日历。
这意味着TravelBuddy需要替用户Alice调用Google Calendar API——读取已有事件、写入新事件。
倒退到2005年，还没有OAuth这种东西，怎么解决？
最直接的办法：让Alice把她的Google账号密码交给TravelBuddy。她在TravelBuddy的界面上输入密码，应用把密码存进数据库，需要读写日历时就拿这组凭据登录Google。
这办法能跑，但隐患大到不可接受。
第一，权限过度。TravelBuddy只需要管日历，但拿着Alice的Google密码，它能读Gmail、翻Google Drive文件、删照片、改账户密码。没办法只给有限权限。
第二，撤销控制粗糙。Alice想停掉TravelBuddy的访问权限，唯一的选择是改Google密码。一改，此前授权过的所有应用全断。
第三，存储连带责任。TravelBuddy的数据库里存着成千上万用户的Google凭据，一次SQL注入或数据库泄露，等于把用户整个数字生活的主钥匙交出去了。
第四，钓鱼行为常态化。训练用户把主力账户密码敲进第三方应用，本身就是最糟的安全习惯。
真正的需求是：让Alice能授权TravelBuddy在Google日历上执行特定操作，但永远不必交出她的Google密码。
这个能力叫“委托授权”，也正是OAuth 2.0要解决的核心问题。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
