OAuth2.0系列之基本概念和运作流程(一)

@TOC

一、OAuth2.0是什么?

1.1 OAuth2.0简介

OAuth 2.0是目前最流行的授权机制,用来授权第三方应用

OAuth是一种开放协议, 允许用户让第三方应用以安全且标准的方式获取该用户在某一网站,移动或者桌面应用上存储的秘密的资源(如用户个人信息,照片,视频,联系人列表),而无需将用户名和密码提供给第三方应用。

OAuth 1.0协议(RFC5849)作为一个指导性文档发布,是一个小社区的工作成果。
本标准化规范在OAuth 1.0的部署经验之上构建,也包括其他使用案例以及从更广泛的IETF社区收集到的可扩展性需求。

OAuth 2.0协议不向后兼容OAuth 1.0。这两个版本可以在网络上共存,实现者可以选择同时支持他们。

1.2 OAuth2.0官方文档

官网:https://oauth.net/2/ ,官网只有英文版文档,您也可以参考翻译过来的文档,链接:OAuth2 RFC6749中文翻译

OAuth2.0在安全性方面做了比较大的提高,简单来说OAuth2.0就是一种授权协议,可以用来授权,随意点个网站,如图这种网站,用户不想注册,就可以用微信、支付宝登录,就是场景是很常见的,也是OAuth2.0的应用


在这里插入图片描述

二、OAuth2.0原理

OAuth2.0是一种授权机制,正常情况,不使用OAuth2.0等授权机制的系统,客户端是可以直接访问资源服务器的资源的,为了用户安全访问数据,在访问中间添加了Access Token机制。客户端需要携带Access Token去访问受到保护的资源。所以OAuth2.0确保了资源不被恶意客户端访问,从而提高了系统的安全性。

2.1 OAuth2.0流程图

引用官方图片介绍OAuth2.0总体流程:


在这里插入图片描述
  • (A)客户端向从资源所有者请求授权。
  • (B)客户端收到授权许可,资源所有者给客户端颁发授权许可(比如授权码code)
  • (C)客户端与授权服务器进行身份认证并出示授权许可(比如授权码code)请求访问令牌。
  • (D)授权服务器验证客户端身份并验证授权许可,若有效则颁发访问令牌(accept token)。
  • (E)客户端从资源服务器请求受保护资源并出示访问令牌(accept token)进行身份验证。
  • (F)资源服务器验证访问令牌(accept token),若有效则满足该请求。

三、 OAuth2.0的角色

OAuth2.0定义如下角色:

引用OAuth2 RFC6749中文翻译

  • 资源所有者(Resource Owner): 能够许可受保护资源访问权限的实体。当资源所有者是个人时,它作为最终用户被提及。
  • 用户代理(User Agent): 指的的资源拥有者授权的一些渠道。一般指的是浏览器、APP
  • 客户端(Client) 使用资源所有者的授权代表资源所有者发起对受保护资源的请求的应用程序。术语“客户端”并非特指任何特定的的实现特点(例如:应用程序是否在服务器、台式机或其他设备上执行)。
  • 授权服务器(Authorization Server): 在成功验证资源所有者且获得授权后颁发访问令牌给客户端的服务器。
    授权服务器和资源服务器之间的交互超出了本规范的范围。授权服务器可以和资源服务器是同一台服务器,也可以是分离的个体。一个授权服务器可以颁发被多个资源服务器接受的访问令牌。
  • 资源服务器(Resource Server): 托管受保护资源的服务器,能够接收和响应使用访问令牌对受保护资源的请求。

四、OAuth2.0授权模式

OAuth2.0有4种授权模式:

  • 授权码模式(authorization code)
  • 简化模式(implicit)
  • 密码模式(resource owner password credentials)
  • 客户端模式(client credentials)

其中最常用的是授权码模式,4种授权模式的详细介绍可以参考阮一峰老师的:OAuth 2.0 的四种方式

4.1 授权码模式(authorization code)

授权码(authorization code)方式,指的是第三方应用先申请一个授权码,然后再用该码获取令牌。

官网图片:


在这里插入图片描述

从调接口方面,简单来说:

  • 第一步:获取code:
    eg:oauthServer+"/oauth/authorize?client_id="+clientId+"&response_type=code&redirect_uri="+redirectUrl+"&scope=all"
    如果没有登录,则会跳转到统一身份认证登录页面。如果用户登录了,调用接口后,会重定向到redirect_uri,授权码会作为它的参数

  • 第二步:获取access_token
    eg:oauthServer+"/oauth/token?code="+code+"&grant_type=authorization_code&client_secret="+clientSecret+"&redirect_uri="+redirectUri+"&client_id="+clientId

{
    "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE1ODk1MzQ5NzMsInVzZXJfbmFtZSI6Im5pY2t5IiwiYXV0aG9yaXRpZXMiOlsiUk9MRV9hZG1pbiJdLCJqdGkiOiJmMjM0M2Q0NC1hODViLTQyOGYtOWE1ZS1iNTE4NTAwNTM5ODgiLCJjbGllbnRfaWQiOiJvYSIsInNjb3BlIjpbImFsbCJdfQ.LWkN2gC2dBrGTn5uSPzfdW6yRj7jhlX87EE8scY02hI",
    "token_type": "bearer",
    "expires_in": 59,
    "scope": "all",
    "user_name": "nicky",
    "jti": "f2343d44-a85b-428f-9a5e-b51850053988"
}
  • 第三步:访问系统资源,此时统一认证服务会根据该认证客户端权限信息判断,决定是否返回信息。

访问:http://localhost:8084/api/userinfo?access_token=${accept_token}

4.2 简化模式(implicit grant type)

简化模式(implicit grant type)不通过第三方应用程序的服务器,直接在浏览器中向认证服务器申请令牌,跳过了"授权码"这个步骤,因此称简化模式

在这里插入图片描述

从调接口方面,简单来说:

  • 第一步:访问授权,要传client_id:客户端id,redirect_uri:重定向uri,response_type为token,scope是授权范围,state是其它自定义参数

http://localhost:8888/oauth/authorize?client_id=cms&redirect_uri=http://localhost:8084/callback&response_type=token&scope=read&state=123

  • 第二步:授权通过,会重定向到redirect_uri,access_token码会作为它的参数

http://localhost:8084/callback#access_token=${accept_token}&token_type=bearer&state=123&expires_in=120

  • 第三步:拿到acceptToken之后,就可以直接访问资源

http://localhost:8084/api/userinfo?access_token=${accept_token}

4.3 密码模式(resource owner password credentials)

密码模式中,用户向客户端提供自己的用户名和密码,这通常用在用户对客户端高度信任的情况

在这里插入图片描述

从调接口方面,简单来说:

  • 第一步:直接传username,password获取token

http://localhost:8888/oauth/token?client_id=cms&client_secret=secret&username=admin&password=123456&grant_type=password&scope=all

  • 第二步:拿到acceptToken之后,就可以直接访问资源

http://localhost:8084/api/userinfo?access_token=${accept_token}

4.4 客户端模式(client credentials)

客户端模式(client credentials)适用于没有前端的命令行应用,即在命令行下请求令牌

在这里插入图片描述

从调接口方面,简单来说:

  • 第二步:拿到acceptToken之后,就可以直接访问资源

http://localhost:8084/api/userinfo?access_token=${accept_token}

学习必要的理论知识后,还是实践一下才能明白整个流程,详情参考我OAuth2.0系列博客专栏:OAuth2.0系列博客,SpringBoot的参考我系列博客专栏:SpringBoot系列博客

五、优质参考资料

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 204,921评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 87,635评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 151,393评论 0 338
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,836评论 1 277
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,833评论 5 368
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,685评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,043评论 3 399
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,694评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 42,671评论 1 300
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,670评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,779评论 1 332
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,424评论 4 321
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,027评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,984评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,214评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,108评论 2 351
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,517评论 2 343