OAuth 2.0实战课
王新栋
京东资深架构师
立即订阅
2439 人已学习
课程目录
已完结 17 讲
0/2登录后,你可以任选2讲全文学习。
开篇词 (1讲)
开篇词 | 为什么要学OAuth 2.0?
免费
基础篇 (6讲)
01 | OAuth 2.0是要通过什么方式解决什么问题?
02 | 授权码许可类型中,为什么一定要有授权码?
03 | 授权服务:授权码和访问令牌的颁发流程是怎样的?
04 | 在OAuth 2.0中,如何使用JWT结构化令牌?
05 | 如何安全、快速地接入OAuth 2.0?
06 | 除了授权码许可类型,OAuth 2.0还支持什么授权流程?
进阶篇 (8讲)
07 | 如何在移动App中使用OAuth 2.0?
08 | 实践OAuth 2.0时,使用不当可能会导致哪些安全漏洞?
09 | 实战:利用OAuth 2.0实现一个OpenID Connect用户身份认证协议
10 | 串讲:OAuth 2.0的工作流程与安全问题
11 | 实战案例:使用Spring Security搭建一套基于JWT的OAuth 2.0架构
12 | 架构案例:基于OAuth 2.0/JWT的微服务参考架构
13 | 各大开放平台是如何使用OAuth 2.0的?
14 | 查漏补缺:OAuth 2.0 常见问题答疑
结束语 (2讲)
期末测试 | 一套习题,测试你的掌握程度
结束语 | 把学习当成一种习惯
OAuth 2.0实战课
15
15
1.0x
00:00/00:00
登录|注册

07 | 如何在移动App中使用OAuth 2.0?

王新栋 2020-07-14
你好,我是王新栋。
在前面几讲中,我都是基于 Web 应用的场景来讲解的 OAuth 2.0。除了 Web 应用外,现实环境中还有非常多的移动 App。那么,在移动 App 中,能不能使用 OAuth 2.0 ,又该如何使用 OAuth 2.0 呢?
没错,OAuth 2.0 最初的应用场景确实是 Web 应用,但是它的伟大之处就在于,它把自己的核心协议定位成了一个框架而不是单个的协议。这样做的好处是,我们可以基于这个基本的框架协议,在一些特定的领域进行扩展。
因此,到了桌面或者移动的场景下,OAuth 2.0 的协议一样适用。考虑到授权码许可是最完备、最安全的许可类型,所以我在讲移动 App 如何使用 OAuth 2.0 的时候,依然会用授权码许可来讲解,毕竟“要用就用最好的”。
当我们开发一款移动 App 的时候,可以选择没有 Server 端的 “纯 App” 架构,比如这款 App 不需要跟自己的 Server 端通信,或者可以调用其它开放的 HTTP 接口;当然也可以选择有服务端的架构,比如这款 App 还想把用户的操作日志记录下来并保存到 Server 端的数据库中。
那总结下来呢,移动 App 可以分为两类,一类是没有 Server 端的 App 应用,一类是有 Server 端的 App 应用。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《OAuth 2.0实战课》,如需阅读全部文章,
请订阅文章所属专栏新⼈⾸单¥9.9
立即订阅
登录 后留言

精选留言(15)

  • 青峰
    请问老师,如果采用第一种办法生成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-14
    4
  • 哈德韦
    如果 Web 端也采用 PKCE 协议,是不是也不需要服务器端了(既纯Web前端也可以对接 OAuth 服务)?

    作者回复: PKCE是OAuth 2.0 的一个增订”协议“,来解决【公共客户端】授权码可能遭劫持的问题。公共客户端无法保存配置时的秘钥等信息。Web应用有自己的服务端支持,可以很好的解决秘钥的保存问题,所以Web应用是不建议这样做的,而且移动App也不建议这做我们课程中给出了建议。如果你确实不需要一个服务端的移动App可以尝试这样的方式,PKCE是RFC 7636的内容。

    2020-07-14
    2
  • 往事随风,顺其自然
    “迷你”的 Web 服务器嵌入到 App 里面去,这个不大理解。
     App 通过监听运行在 localhost 上的 Web 服务器 URI 这个是怎么实现的?

    作者回复: 移动App类应用不像Web应用或者浏览器应用那样可以让用户通过浏览器来访问,如果为了实现这样的方式,可以尝试的做法是需要移动App类应用能够访问操作系统上的浏览器,为了能够监听到这个前端的响应,还需要通过一个URI提供服务,可以通过一个微型的内嵌在应用内、运行在localhost上的Web服务器。

    2020-07-16
    1
    1
  • leros
    在PKCE协议下,第三方应用掌握了太多的秘密(verifier, challenge),考虑到移动终端千差万别,保证第三方应用的安全并不容易

    作者回复: 移动端类应用,目前各大开放平台都是要求必须有第三方的服务端的支持,由第三方的服务端来跟平台做交互通信。2012年10月发布了OAuth 2.0 的正式授权协议框架,也就是官方的RFC 6749,在2015年9月增补了PKCE协议,也就是官方的RFC 7636。PKCE发布的目的是为了缓解针对公开客户端的攻击,主要是解决授权码窃听的攻击。

    2020-07-16
    1
  • Ryan Pan
    请问如果移动App是自家的,用资源拥有者授权的话,app secret建议存哪里呢?

    作者回复: 存在服务端,有一个专有的秘钥服务器,但只用户登录之后换回access_token然后才可以去请求或者操作【带有用户属性】的数据。

    2020-07-14
    1
  • Geek_7b3867
    老师,在有服务器的情况下,详细的那个图中是会拉起微信进行用户授权,这样到了微信开放平台是可以验证是谁授权的;但是无服务器的情况下,生成code_verifier和code_challenge过程并未看到用户授权,这两个值传到微信后台如何判断是谁授权的?如何校验?
    2020-08-11
  • 我行我素
    请问:code_verifier在app端随机生成,服务端也不知道结果,那么怎么验证是否是合法的呢?
    2020-08-05
  • sanmao
    有一个这样的场景, 我在负责公司的开放平台, 现在公司有一款小程序需要使用这个开放平台. 现在有两个问题困扰了我. 1: 这样要对接多个开放平台的小程序认证流程该如何设计. 2: 已经在微信公众平台认证过的小程序, 再接入公司的开放平台的这个认证过程怎么设计比较合理.
    2020-07-31
  • Geek_9ae2b9
    对比了PKCE 协议和隐式许可,两种都是适用于没有Server端的场景。但PKCE 协议感觉更安全,既然如此为什么还需要隐式许可呢?

    作者回复:
    可以理解为PKCE是一种增强

    2020-07-20
  • 微风
    没有 Server 端的 App用例中,如果授权码 code 被截获,再加上 code_challenge 也同时被截获了。那就可以伪造回去token了。怎么保证安全的?
    2020-07-19
  • Harvey
    用code_verifier验证code_challenge通过只能证明后一次请求和前一次是从同一个客户端发起的吧?怎么能起到app_secret证明客户端是谁是否合法的作用呢?

    作者回复:
    PKCE机制可以【减轻】针对授权码截获的攻击,公共客户端固有的局限性PKCE并不能解决,所以它起不到secret的作用。

    另外,PKCE是OAuth 2.0的一个增补协议可以单独使用,也可以组合使用,比如,如果在具备保存secret的环境里面已经使用授权码流程的基础上再增加PKCE的支持,将会进一步增强授权码流程的安全性。

    2020-07-17
  • suhuijie
    微信自己登陆用的什么机制,也是OAuth还是?

    作者回复: 微信提供的联合登录肯定是OAuth,至于微信app自身内部使用了什么,这个还需要再确认。

    2020-07-16
  • 一步
    如果拿到 app_id 是不是就可以冒充该客户端短了? 还是授权服务还必须要验证 app_id 和 redirect_uri
    绑定关系的?

    作者回复: PKCE的推出是为了解决使用授权码许可类型的公开客户端容易遭到授权码窃听的攻击的问题。但是对于公开客户端固有的弊端PKCE是解决不了的。

    为了【缓解】这种针对公开客户端的攻击,OAuth发布了一个附加规范,也就是我们说的PKCE。

    2020-07-15
  • carol
    code_verifier是不是就可以理解为一个随机字符串

    作者回复: 可以

    2020-07-15
  • inrtyx
    如果请求code的参数和请求token的参数都被截取了,那不就可以反推code_verifier?
    2020-07-14
    1
收起评论
15
返回
顶部