搞懂oauth2.0授权码模式

OAuth 2.0 是什么?

举一个电商的场景,你估计更有感觉。假如你是一个卖家,在京东商城开了一个店铺,日常运营中你要将订单打印出来以便给用户发货。但打印这事儿也挺繁琐的,之前你总是手工操作,后来发现有个叫“小兔”的第三方软件,它可以帮你高效率地处理这事。

  但你想想,小兔是怎么访问到这些订单数据的呢?其实是这样,京东商城提供了开放平台,小兔通过京东商家开放平台的 API 就能访问到用户的订单数据。

  只要你在软件里点击同意,小兔就可以拿到一个访问令牌,通过访问令牌来获取到你的订单数据帮你干活儿了。你看,这里也是有一次授权。你要是不同意,平台肯定不敢把这些数据给到第三方软件。

为什么用 OAuth 2.0?

OAuth 2.0 这种授权协议,就是保证第三方(软件)只有在获得授权之后,才可以进一步访问授权者的数据。因此,我们常常还会听到一种说法,OAuth 2.0 是一种安全协议。现在你知道了,这种说法也是正确的。

  现在访问授权者的数据主要是通过 Web API,所以凡是要保护这种对外的 API 时,都需要这样授权的方式。而 OAuth 2.0 的这种颁发访问令牌的机制,是再合适不过的方法了。同时,这样的 Web API 还在持续增加,所以 OAuth 2.0 是目前 Web 上重要的安全手段之一了。

OAuth 2.0 是怎样运转的?

搞懂oauth2.0授权码模式_第1张图片

 图中的流程只是授权码的方式

为什么需要授权码

搞懂oauth2.0授权码模式_第2张图片

1.access_token不显示在浏览器是因为安全原因

2.浏览器直接获取调用授权带着回调,然后授权服务器把access_token直接返回给服务器行不行?

 首先access_token需要secret,客户端不能存储,所以请求access_token必须通过服务端。如果取消授权码模式,客户端需要更复杂的签名加密方式去把secret传递过去获取access_token。

  • Http 协议是无状态的,“第三方服务器”无法从一个 Server 对 Server 的请求轻易区分这个 token 对着自己当前哪个 Session。
  • 如果依赖第一步里,“第三方服务器”跳转到“认证服务器”时传递的 GET 参数来作为 Session 身份区分,又涉及到跳转本身就是明文,可能被篡改的问题,需要协定复杂的签名协议来保证安全,这和 OAuth2 希望设计简洁验证模式的初衷违背。
  • 假设安全问题解决了,已跳转回来的“第三方服务器”网页需要等待一个不知道何时才会过来的“认证服务器” Server 回调,才能告诉用户到底授权成功没有。远不如同步主动去请求“认证服务器”获取方便。

-----------------------------------以后是旧内容---------------------------------

最早的简单登录

搞懂oauth2.0授权码模式_第3张图片

去访问一个网站,如果登录的话,需要注册,填一堆信息,用户名密码啥的,通常密码是前端加盐、哈希(md5,sha1等)然后再发给后端,后端存储起来,不能直接存储明文。然后再跳转到登录页面,输入用户名和密码,后端验证用户名和密码,如果成功了返回一个session id,然后前端就可以结合cookie使用。

问题:

1.安全性,需要对密码的加密有一个万全的应对之策

2.维护麻烦,用户用起来也麻烦

比较早的授权登录

后来yelp试图解决这些问题,如下图所示

搞懂oauth2.0授权码模式_第4张图片

想用什么登录就选中,但是得需要对应的用户和密码,然后yelp会用密码去google拉取你的相关信息。

问题:

1.安全性,虽然yelp承诺了不保存用户google的密码,但是可能是小公司,没有信用累积(谁知道背着用户有没有在后台做什么)

OAuth2.0授权登录

为了解决这些问题,oauth2.0授权登录出现了

上个流程换用oauth2.0的流程就变成下面的了

搞懂oauth2.0授权码模式_第5张图片

小公司不值得信任,但是我信任google,所以yelp与google建立联系

用户点击使用google登录,然后跳转到google的登录页面,输入自己google的账号和密码,然后弹出一个框,是否同意yelp访问你的个人信息和通讯录信息

如果你点否,那么yelp将会什么都不做,可能也无法登录

如果点击是,会回调到yelp的某个页面,然后yelp的后台会去访问google你的信息和页面,通过某种介质

搞懂oauth2.0授权码模式_第6张图片

这个流程总结为我授权yelp去google可以拿到我的个人信息和通讯录

oauth2.0的一些名词的解析

Resource owner: 资源的拥有者, 即想使用google登录yelp的用户

Client: 客户端 即yelp app 

Authorization server:授权服务,即上述流程中的account.google.com,在这里你登录了google,并且同意了授权

Resource server:资源服务,即上述流程中的contacts.google.com,存储你相关信息的服务

Authorization grant(这个好像是scops):同时赋予某种权限,图中赋予了个人信息和通讯录的权限

Redirect URI: 回调URL,即上述流程中,授权成功后,跳转回的那个callback url

Access Token : 去访问Resource server的令牌,即上述流程中yelp后台通过这个可以去google访问,获取到你同意的那些信息(个人信息,通讯录)

oauth2.0的授权码流程

搞懂oauth2.0授权码模式_第7张图片

用户使用google授权登录,yelp跳转到google的Authorization server, 通过下图的uri, 指定回调url,response type:code授权码方式,以及想要获取哪些授权,这里是profile 和 contacts。

搞懂oauth2.0授权码模式_第8张图片

然后如果没有登录,用户登录,成功后,跳转询问用户是否同意上述授权

如果同意了,又调回到我们指定的回调url,并且带着授权码,如下图

搞懂oauth2.0授权码模式_第9张图片

第一个uri是用户点否后,回调的uri 

第二个uri是用户点击是后,回调的uri

拿到这个uri后, client 即会访问这个uri,请求到yelp的后端进行应该的操作

假设用户同意授权,即yelp后端会用授权码 去换取token, 通过token在yelp后端再拿到用户的信息 

多了授权码这一步,就是为了避免access_token在前端暴露,  加强了安全性

搞懂oauth2.0授权码模式_第10张图片

上图就是前端拿到uri后,访问后端,后端要进行的操作,即用授权码和你再google注册的client_id,client_secret 来交换access_token。 ps:回调url也是在google注册的时候填写的。搞懂oauth2.0授权码模式_第11张图片

上图即拿code交换access_token的响应body ps:少了refresh_token, 这个东西的过期时间会更长,一般access_token过期后,不用再走授权码的流程,只需要拿refresh_token去换取新的access_token和refresh_token即可。

问题:

oauth2.0是授权不是认证,所以用它拿来做用户认证是不正确的 

而且oauth2.0不是一个标准的协议,各家实现都有差异。 

为了解决这些问题,OpenID Connect的概念随即被提出

OpenID Connect

搞懂oauth2.0授权码模式_第12张图片

如图所示,oauth2.0是授权authorization ,OpenID Connect是认证 authentication

OpenID Connect在oauth2.0的基础上封装了一层,支持了用户认证。 也同样支持授权码方式,也oauth2.0不同的时返回了ID Token,用来做认证。下面看一下OpenID Connect的授权码流程

搞懂oauth2.0授权码模式_第13张图片

1.Scope:必须指定openid

2.ID token与 access_token一起返回

这2点是与oauth2.0不同的地方,其他的都类似。

搞懂oauth2.0授权码模式_第14张图片

搞懂oauth2.0授权码模式_第15张图片

搞懂oauth2.0授权码模式_第16张图片

多了个id_token, 一般是用jwt协议实现的,(jwt是啥,可以看我另一篇文章) 如下所示

搞懂oauth2.0授权码模式_第17张图片

搞懂oauth2.0授权码模式_第18张图片

获取用户信息

oauth2.0和OpenID Connect

搞懂oauth2.0授权码模式_第19张图片

搞懂oauth2.0授权码模式_第20张图片这里指的是OpenID Connect 

搞懂oauth2.0授权码模式_第21张图片

搞懂oauth2.0授权码模式_第22张图片搞懂oauth2.0授权码模式_第23张图片

撤销token

搞懂oauth2.0授权码模式_第24张图片

你可能感兴趣的:(认证,oauth2.0,后端,OpenID,Connect)