关于java:这些OAuth2客户端的认证方式你未必了解

2次阅读

共计 1816 个字符，预计需要花费 5 分钟才能阅读完成。

OAuth2客户端依照它们与受权服务器进行平安认证的能力能够分为秘密类型（Confidential）和公共类型（Public）。

秘密类型的本身会有个明码凭据，比方 Web 服务器后端程序；而公共类型则没有明码凭据，纯浏览器前端利用或者挪动客户端利用大都属于这一种类型。不论是哪一种，它们都有客户端 ID（client_id）。

客户端在执行 OAuth2 受权的敏感流程中（相干的流程有令牌申请、令牌自省申请、令牌撤销申请）必须应用受权服务器进行客户端身份验证，确保客户端中途不会被调包。

目前客户端认证的形式有以下几种:

后面 Gitee 的DEMO应用的是过期的 POST 形式；微信 DEMO 应用的是非 OAuth2 规范的形式；Spring Authorization Server目前相干的 DEMO 应用的是 client_secret_basic 形式。剩下的形式中 client_secret_jwt 和private_key_jwt用的比拟多，这两种形式能够很好地爱护客户端的认证信息，安全性更高。Spring Security和 Spring Authorization Server 目前曾经反对这两种形式。

client_secret_jwt形式是 OAuth2 客户端将本人的密钥作为 HmacSHA256 算法的 key 生成SecretKey：

byte[] pin = clientSecret.getBytes(StandardCharsets.UTF_8);
SecretKeySpec  secretKey = new SecretKeySpec(pin,"HmacSHA256");

而后通过 SecretKey 生成一个携带 OAuth2 客户端信息的 JWT，在受权码申请Token 环节携带该 JWT 以便受权服务器进行客户端认证，申请的报文为:

     POST /oauth2/token HTTP/1.1
     Host: oauth2_client.felord.cn
     Content-Type: application/x-www-form-urlencoded

     grant_type=authorization_code&
     code=n0esc3NRze7LTCu7iYzS6a5acc3f0ogp4&
     client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer&
     client_assertion= 你的 JWT

受权服务器收到申请后通过 OAuth2 客户端的 client_secret 对JWT进行解码校验以认证客户端。这种形式能很好的爱护 client_secret 在非 HTTPS 环境下的传输。

这里 OAuth2 客户端的密钥（client_secret）比特长度必须大于等于256。

private_key_jwt和 client_secret_jwt 惟一的区别就是生成 JWT 的形式不同。通过这种形式，OAuth2客户端曾经不须要 client_secret，只须要配置一对RSA 或者 EC 密钥，通过密钥来生成JWT，另外还须要向受权服务器提供公钥，通常是一个jwkSetUrl。该形式的细节曾经在 OAuth2 专栏中 JOSE 标准一文中进行过具体阐明了，这里不再赘述。这种形式让客户端的认证信息更加平安的传输，是我集体比拟喜爱的形式。

这个比拟高级，嵌入了 TLS 平安层，在 HTTP 协定级别来认证 OAuth2 客户端，它波及的证书来自可信赖的CA。这种形式根本脱离了应用层，是一种无侵入的形式。

这个同样也是在 TLS 平安层，不过它应用了自签名的 X.509 证书。

市面上的教程大多只会提到过期的 ~~POST~~ 形式以及 client_secret_basic 和client_secret_post形式，对前面的五种则很少波及，胖哥曾经对 private_key_jwt 和client_secret_jwt进行了实现，具体请订阅我的 Spring Security OAuth2 专栏。这些 OAuth2 客户端认证形式在不同的场景有不同的劣势，你能够依据不同的安全级别抉择不同的 OAuth2 客户端认证形式。

关注公众号：Felordcn 获取更多资讯

集体博客：https://felord.cn

正文完