php oauth认证关键在三处：state须服务端random_bytes(16)生成并校验防csrf；authcodegrant必须显式设authcodettl（如pt10m）避免invalid_grant；client_credentials请求必须用authorization头传base64凭据，不可放body。
直接上结论：PHP OAuth认证不是“调通接口就完事”，关键在三处——state必须服务端生成并校验、authorization_code换access_token时的authCodeTTL要显式设长、client_credentials请求必须走Authorization头而非POST body。漏掉任一，上线后就是高危漏洞或50%失败率。
为什么 authorization_code 换 token 总是 invalid_grant？
这不是密钥填错或网络问题，而是服务端实现细节卡住的典型现象。
-
AuthCodeGrant构造时没传$authCodeTTL，默认只有60秒，用户点授权+跳转稍慢就过期；建议设为new \DateInterval('PT10M') - 没实现
ClientRepositoryInterface和AccessTokenRepositoryInterface——哪怕只用内存数组也得写，否则scope校验、token过期、revoke全失效 -
respondToAccessTokenRequest()内部已输出JSON并设好Content-Type: application/json和状态码，你再echo json_encode()就会触发“headers already sent”错误
client_credentials 请求为什么 401？
它根本不是权限问题，是认证头格式不对。league/oauth2-server 默认只从Authorization请求头读取Basic凭据，不解析POST body。
- 请求必须带
Authorization: Basic base64(client_id:client_secret)，不能把client_id和client_secret塞进form-data或JSON body - 检查数据库中
clients表的secret字段是否被trim()过——MySQLTEXT类型可能自动截掉末尾空格，导致base64解码后密钥错误 - 调试时用
var_dump($request->getHeaderLine('Authorization'))确认头是否到达，再查$server->validateClient($request)返回false的具体原因
state 参数不校验会出什么问题？
CSRF攻击可直接伪造整个授权流程，把用户引向恶意回调地址，窃取code进而换取access_token。
-
state必须用random_bytes(16)生成，再转成十六进制（如bin2hex(random_bytes(16))），长度≥32字符 - 绝不能靠前端JS生成——攻击者可完全控制跳转链路
- 回调页必须先检查
$_GET['state']是否存在，再严格比对$_SESSION['oauth2state']，不一致立即exit()；比对后立刻unset($_SESSION['oauth2state'])，防重放
最易被忽略的是：所有access_token都该由后端保管，严禁存localStorage或明文写入Cookie；若需前端使用，应加密后存HttpOnly Cookie，且生命周期严格匹配token过期时间。这一步不做，等于把门钥匙焊在门把手上。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
