模式|OAuth 2.0 扩展协议之 PKCE( 二 )_服务|攻击|Code|OAuth|应用|

授权码拦截攻击

文章图片

上面是OAuth 2.0授权码模式的完整流程，授权码拦截攻击就是图中的C步骤发生的，也就是授权服务器返回给客户端授权码的时候，这么多步骤中为什么C步骤是不安全的呢? 在OAuth 2.0核心规范中，要求授权服务器的anthorize endpoint和token endpoint必须使用TLS（安全传输层协议）保护，但是授权服务器携带授权码code返回到客户端的回调地址时，有可能不受TLS 的保护，恶意程序就可以在这个过程中拦截授权码code ，拿到 code 之后，接下来就是通过code向授权服务器换取访问令牌access_token ，对于机密的客户端来说，请求access_token时需要携带客户端的密钥 client_secret ，而密钥保存在后端服务器上，所以恶意程序通过拦截拿到授权码code 也没有用，而对于公开的客户端（手机App ，桌面应用）来说，本身没有能力保护 client_secret ，因为可以通过反编译等手段，拿到客户端client_secret ，也就可以通过授权码code换取access_token ，到这一步，恶意应用就可以拿着token请求资源服务器了。
state参数，在OAuth 2.0核心协议中，通过code换取token步骤中，推荐使用state参数，把请求和响应关联起来，可以防止跨站点请求伪造-CSRF攻击，但是state并不能防止上面的授权码拦截攻击，因为请求和响应并没有被伪造，而是响应的授权码被恶意程序拦截。
PKCE 协议流程

文章图片

PKCE协议本身是对OAuth 2.0的扩展，它和之前的授权码流程大体上是一致的，区别在于，在向授权服务器的authorize endpoint请求时，需要额外的code_challenge和code_challenge_method参数，向token endpoint请求时，需要额外的code_verifier参数，最后授权服务器会对这三个参数进行对比验证，通过后颁发令牌。
code_verifier
对于每一个OAuth授权请求，客户端会先创建一个代码验证器code_verifier ，这是一个高熵加密的随机字符串，使用URI非保留字符 (Unreserved characters) ，范围[A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~" ，因为非保留字符在传递时不需要进行URL 编码，并且 code_verifier 的长度最小是43 ，最大是128 ， code_verifier要具有足够的熵它是难以猜测的。
code_verifier的扩充巴科斯范式 (ABNF) 如下:

code-verifier= 43* 128unreservedunreserved= ALPHA / DIGIT / "-"/ "."/ "_"/ "~" ALPHA= %x41- 5A / %x61- 7ADIGIT= %x30- 39 简单点说就是在[A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~"范围内，生成43-128位的随机字符串。

模式|OAuth 2.0 扩展协议之 PKCE( 二 )

推荐阅读

如何找寻自我

缝纫机调线器怎么安装平车方法如何

强组词强字组词

火笋鸡翅的做法（增肥食谱）

闺女生日快乐祝福语朋友圈

LV请来潮牌设计师做艺术总监，看中的是啥

老虎豆怎么做好吃老虎豆图片怎样弄来吃

暖气有流水声是什么原因

皮球是什么体

手机怎样开通QQ空间

男生发mua说明 mua是什么意思

手指盖凹陷怎么回事

对自己的生活失去掌控咋调整

小米10s怎么没有月亮模式

我想找个偏僻的地方搞养殖！有没有推荐的地方？

南京养老金认证上门服务怎么申请南京市养老金认证

如何评价猪场阉割猪？

最后一个字是豹的成语

泰山散酒怎么样

猫发情的声音(猫发情的叫声)