07 | 如何在移动App中使用OAuth 2.0？
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
移动App中使用OAuth 2.0的关键在于安全获取访问令牌。本文介绍了在没有Server端的App应用中，使用PKCE协议实现安全的授权码许可类型。通过生成code_verifier和code_challenge参数，PKCE协议在没有app_secret的情况下，仍能安全进行授权。文章强调了PKCE协议的安全性，并提到了通过后端通信来换取访问令牌是更安全的方式。因此，文章提出了对于移动应用开发是否真的不需要一个Server端的思考。通过具体的流程图和代码示例，清晰地解释了PKCE协议的实现原理和安全性，为移动App中使用OAuth 2.0提供了有益的指导。文章还介绍了有Server端的App如何使用OAuth 2.0的授权码许可流程。总结强调了OAuth 2.0协议的安全性作用，以及建议在开发移动App时尽可能搭建一个Server端。文章内容深入浅出，为读者提供了对OAuth 2.0的安全方面防范措施的重要思考。
《OAuth 2.0 实战课》，新⼈⾸单¥29
全部留言(31)
- 最新
- 精选
青峰请问老师，如果采用第一种办法生成code_verifier，code_challenge_method=plain，那么code_verifier 的值就是 code_challenge 的值。 这时候，不是获得了code_challenge 就可以推出 code_verifier 的值了吗？作者回复: 在这种code_challenge_method=plain情况下，code_verifier的值和code_challenge的值是一样的。 我们首先要清楚PKCE的出现是为了解决，客户端如果不想使用服务端来支持，在失去了secret的保护下，怎么让OAuth 2.0 进行的更安全，实际上是为了防止授权码被截获，授权码的截获是发生在授权服务响应客户端【第一次】请求授权码的这个过程里面。 在code_verifier的值和code_challenge的值是一样的情况下，是做了一个最基本的校验，当客户端【第二次】拿着授权码code和code_verifier来请求access_token的时候，授权服务会判断这次给的code_verifier和上次给的code_challenge值是否一致，如果不一致，拒绝返回access_token。 code_challenge_method=plain、code_challenge_method=S256、给客户端增加一个服务端支持，这三种情况的安全等级是逐渐增高的。 安全问题的发生是一个组合问题，安全问题的防护是一个成本问题。
2020-07-1418
Harvey用code_verifier验证code_challenge通过只能证明后一次请求和前一次是从同一个客户端发起的吧？怎么能起到app_secret证明客户端是谁是否合法的作用呢？作者回复: PKCE机制可以【减轻】针对授权码截获的攻击，公共客户端固有的局限性PKCE并不能解决，所以它起不到secret的作用。 另外，PKCE是OAuth 2.0的一个增补协议可以单独使用，也可以组合使用，比如，如果在具备保存secret的环境里面已经使用授权码流程的基础上再增加PKCE的支持，将会进一步增强授权码流程的安全性。
2020-07-1710
leros在PKCE协议下，第三方应用掌握了太多的秘密（verifier, challenge)，考虑到移动终端千差万别，保证第三方应用的安全并不容易作者回复: 移动端类应用，目前各大开放平台都是要求必须有第三方的服务端的支持，由第三方的服务端来跟平台做交互通信。2012年10月发布了OAuth 2.0 的正式授权协议框架，也就是官方的RFC 6749，在2015年9月增补了PKCE协议，也就是官方的RFC 7636。PKCE发布的目的是为了缓解针对公开客户端的攻击，主要是解决授权码窃听的攻击。
2020-07-166
往事随风，顺其自然“迷你”的 Web 服务器嵌入到 App 里面去，这个不大理解。 App 通过监听运行在 localhost 上的 Web 服务器 URI 这个是怎么实现的？作者回复: 移动App类应用不像Web应用或者浏览器应用那样可以让用户通过浏览器来访问，如果为了实现这样的方式，可以尝试的做法是需要移动App类应用能够访问操作系统上的浏览器，为了能够监听到这个前端的响应，还需要通过一个URI提供服务，可以通过一个微型的内嵌在应用内、运行在localhost上的Web服务器。
2020-07-1623
哈德韦如果 Web 端也采用 PKCE 协议，是不是也不需要服务器端了（既纯Web前端也可以对接 OAuth 服务）？作者回复: PKCE是OAuth 2.0 的一个增订”协议“，来解决【公共客户端】授权码可能遭劫持的问题。公共客户端无法保存配置时的秘钥等信息。Web应用有自己的服务端支持，可以很好的解决秘钥的保存问题，所以Web应用是不建议这样做的，而且移动App也不建议这做我们课程中给出了建议。如果你确实不需要一个服务端的移动App可以尝试这样的方式，PKCE是RFC 7636的内容。
2020-07-1423- Geek_7b3867老师，在有服务器的情况下，详细的那个图中是会拉起微信进行用户授权，这样到了微信开放平台是可以验证是谁授权的；但是无服务器的情况下，生成code_verifier和code_challenge过程并未看到用户授权，这两个值传到微信后台如何判断是谁授权的？如何校验？
作者回复: 介绍PKCE的时候是为了突出流程，就么有画出用户的角色，生成code_verifier和code_challenge都是在用户点击授权之后产生的，所有的授权流程包括之前讲的授权码等等，都是发生在用户点击了授权按钮之后，才发生的，用户的授权肯定都是在平台上面进行，所以平台一定能够拿到用户的登录态。
2020-08-111 
而立斋code_verifier是不是就可以理解为一个随机字符串作者回复: 可以
2020-07-151
Ryan Pan请问如果移动App是自家的，用资源拥有者授权的话，app secret建议存哪里呢？作者回复: 存在服务端，有一个专有的秘钥服务器，但只用户登录之后换回access_token然后才可以去请求或者操作【带有用户属性】的数据。
2020-07-141- Geek_9ae2b9对比了PKCE 协议和隐式许可，两种都是适用于没有Server端的场景。但PKCE 协议感觉更安全，既然如此为什么还需要隐式许可呢？
作者回复: 可以理解为PKCE是一种增强
2020-07-20 - suhuijie微信自己登陆用的什么机制，也是OAuth还是？
作者回复: 微信提供的联合登录肯定是OAuth，至于微信app自身内部使用了什么，这个还需要再确认。
2020-07-16
