身份API接口这东西，身份说白了就是身份一套让程序去问“你是谁”的规则。你打开一个App，身份点“用微信登录”，身份背后就是身份它在干活。没有它，身份每个网站都得自己存一套用户名密码，身份你得多记几十个账号，身份还得祈祷对方别把数据库弄丢。身份

我头一回认真琢磨它，身份是身份因为一个做后端的朋友吐槽。他们公司接了个银行的身份身份接口，文档写了三百多页，身份光错误码就列了八十几个。身份他说调通那天，身份感觉自己像考了个证。

它到底在传什么

身份API不传你的脸，也不传你的指纹。它传的是一串叫token的东西。你可以把它想成游乐园的手环——进门时验一次身份证，之后玩项目只看手环。手环本身不包含你的身份证号，但检票员认它。

OAuth 2.0是目前最主流的玩法。流程大概是这样：你的App把用户踢到微信的授权页，用户点“同意”，微信给App一个code，App拿code去换access token。这串token通常几小时就过期，过期了用refresh token再换新的。整个过程用户只输一次密码，还是在微信的地盘上输的，App碰不到。

有个细节挺有意思。token一般不是随机字符串，而是JWT格式——三段用点隔开的Base64，中间那段解码出来能看到用户ID、过期时间、甚至角色权限。服务端拿到token不用查数据库，本地验签就行。快是真快，但吊销麻烦。用户改了密码，旧token在过期前照样能用。所以敏感操作还得再验一次。

现实里的坑

标准归标准，落地是另一回事。我见过一个电商平台，身份接口返回的用户ID是自增整数。结果竞品爬虫从1开始遍历，把用户昵称和头像全抓走了。后来他们改成UUID，性能掉了两成，但至少不被人当靶子打。

还有回调地址的问题。OAuth要求你提前注册redirect_uri，但开发环境、测试环境、生产环境域名不一样。有人图省事，直接填个通配符。攻击者把redirect_uri改成自己的服务器，授权码就送到别人手里了。这种漏洞每年都能扫出一批。

移动端更麻烦。App没有浏览器那么清晰的地址栏，恶意应用可以注册同样的scheme来截胡。Android后来推App Links，iOS推Universal Links，就是想解决这个。但开发者适配进度参差不齐，现在还有大量老App用着自定义scheme裸奔。

选型时的真实考量

自己搭一套身份系统，还是接第三方的？小团队别犹豫，直接接。微信、Google、Apple，哪个用户多接哪个。省下来的时间拿去打磨核心功能。大公司反而倾向于自建，数据主权、合规审计、定制流程，第三方很难满足。

但自建有个隐性成本：安全团队。身份系统是攻击面最大的模块之一，SQL注入、CSRF、会话固定、时序攻击，每个都得防。没有专人盯着，迟早出事。我认识一个创业公司，自建的身份服务被拖库，用户手机号全泄露，融资直接黄了。

接口设计上，返回信息越少越好。用户登录只需要一个稳定ID和昵称，别把邮箱、手机号、生日一股脑塞进token。权限范围（scope）要细粒度，读通讯录和发朋友圈是两码事，别打包成一个“全权限”。

最后说个观察：身份API的文档质量，基本能反映这家公司的工程水平。文档里把错误码、限流策略、token生命周期写清楚的，接口通常也稳。文档只有一句“调用即可”的，你最好多留几天联调时间。