oauth2 授权模式 - 第三方登录

OAuth2.0是一种流行的安全授权协议,允许第三方应用在用户授权下访问用户数据,而不需直接获取用户名和密码。本文详细介绍了四种主要的OAuth2.0授权模式,包括授权码模式、密码模式、简化模式和客户端模式,以及它们的应用场景和流程。
摘要由CSDN通过智能技术生成

Oauth2

OAuth 2.0 是目前最流行的授权机制,用来授权第三方应用,获取用户数据。

OAuth 协议为用户资源的授权提供了一个安全的、开放而又简易的规范标准。与以往的授权方式不同之处是

OAuth 的授权不会使第三方触及到用户的帐号信息(如用户名与密码),即第三方无需使用用户的用户名与密码就

可以申请获得该用户资源的授权,因此 OAuth 是开放的安全的。

业界提供了 OAuth 的多种实现,如 Java、PHP、Ruby 等各种语言开发包,大大节约了程序员的时间,因而OAuth是简易的。很多大公司如 阿里、腾讯、 Google,Yahoo,Microsoft等都提供了 OAuth 认证服务,这些都足以说明 OAuth 标准逐渐成为开放资源授权的标准。

OAuth 协议1.0版本过于复杂,目前发展到2.0版本,2.0版本已得到广泛应用。

说白了:OAuth 就是一种授权机制。数据的所有者告诉系统,同意授权第三方应用进入系统,获取这些数据。系统从而产生一个短期的进入令牌(token),用来代替密码,供第三方应用使用。

oauth2服务组成


第三方应用(Third-party application): 非受信任的系统 ,可以参考微信登录,qq登录 ,csdn想通过微信用户登录 csdn就属于第三方应用 (在前后端分离项目 前端项目也属于第三方应用)
认证服务器(Authorization server): 专门用来对资源所有者的身份进行认证、对要访问的资源进行授权、产生令牌的服务器。想访问资源,需要通过认证服务器由资源所有者授权后才可访问。
资源服务器(Resource server): 微服务系统的业务服务,如用户服务,文件服务,第三方服务想从资源服务器中获取数据。

资源所有者:不是服务组成的部门 为下文概念 就是操作用户本人。


注意:认证服务器 和资源服务器 虽然是两个解决,但其实他们可以是同一台服务器、同一个应用。
服务提供商(Service Provider): 如 QQ、微信等 (包含认证和资源服务器)。

四种模式

比较常用为前两种方式 后两种了解即可

一.授权码模式

功能最完整,流程最严密的授权模式。国内各大服务提供商(微信、QQ、微博、淘宝 、百度)都采用此模式进行授权。可以确定是用户真正同意授权;而且令牌是认证服务器发放给第三方应用的服务器,而不是浏览器上。这种方式跳转的登录页面为被接入系统的页面 所以接入并不会获取到登陆者的账号密码 参考 csdn的微信登录

1.流程

clinet:第三方

authorization server :认证授权服务器

user agent:用户

resource owner:资源拥有者 可以理解为账户所有人. 可以理解为使用者本人 但和使用者不是同一角色

它的步骤如下:

(A)用户(user agent)访问客户端(clinet),后者将前者导向认证服务器。

(B)用户(resource owner)选择是否给予客户端授权。

(C)假设用户(resource owner)给予授权,认证服务器(authorization server)将用户导向客户端(clinet)事先指定的"重定向URI"(redirection URI),同时附上一个授权码。

(D)客户端(clinet)收到授权码,附上早先的"重定向URI",向认证服务器申请令牌。这一步是在客户端的后台的服务器上完成的,对用户不可见。

(E)认证服务器核对了授权码和重定向URI,确认无误后,向客户端(clinet)发送访问令牌(access token)和更新令牌(refresh token)。

二.密码模式

密码模式(Resource Owner Password Credentials Grant)中,用户向客户端提供自己的用户名和密码。客户端使用这些信息,向"服务商提供商"索要授权。大多数当第三方是高度受信任系统 如:本公司的系统接入本公司的系统

1.流程

它的步骤如下:(各角色请参考上文)

他的步骤如下:

  ( A)用户向客户端提供用户名和密码。

(B)客户端将用户名和密码发给认证服务器,向后者请求令牌。

(C)认证服务器确认无误后,向客户端提供访问令牌。

三.简化模式(隐藏式)

简化模式(implicit grant type)不通过第三方应用程序的服务器,直接在浏览器中向认证服务器申请令牌,跳过了"授权码"这个步骤,因此得名。所有步骤在浏览器中完成,令牌对访问者是可见的,且客户端不需要认证。(适用于没有后台的网站)

1.流程

他的步骤:

(A)客户端将用户导向认证服务器。

(B)用户决定是否给于客户端授权。

(C)假设用户给予授权,认证服务器将用户导向客户端指定的"重定向URI",并在URI的Hash部分包含了访问令牌。

(D)浏览器向资源服务器发出请求,其中不包括上一步收到的Hash值。

(E)资源服务器返回一个网页,其中包含的代码可以获取Hash值中的令牌。

(F)浏览器执行上一步获得的脚本,提取出令牌。

(G)浏览器将令牌发给客户端。

四.客户端模式(凭证式)

客户端模式(Client Credentials Grant)指客户端以自己的名义,而不是以用户的名义,向"服务提供商"进行认证。严格地说,客户端模式并不属于OAuth框架所要解决的问题。在这种模式中,用户直接向客户端注册,客户端以自己的名义要求"服务提供商"提供服务,其实不存在授权问题

1.流程

他的步骤:

(A)客户端向认证服务器进行身份认证,并要求一个访问令牌。

(B)认证服务器确认无误后,向客户端提供访问令牌。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
OAuth 2.0是一种常用的协议,可用于实现第三方应用程序对用户资源的授权访问。以下是使用OAuth 2.0进行第三方访问授权的基本流程: 1. 用户启动第三方应用程序并请求访问其受保护的资源。 2. 第三方应用程序将用户重定向到授权服务器,并附带自己的客户端ID和重定向URI。 3. 用户在授权服务器上进行身份验证,并决定是否授权第三方应用程序访问其资源。 4. 授权服务器向用户展示授权请求的权限范围,并要求用户授权。 5. 用户同意授权请求后,授权服务器将用户重定向回第三方应用程序,并携带一个授权码。 6. 第三方应用程序使用授权码向授权服务器请求访问令牌。 7. 授权服务器验证授权码的有效性,并颁发访问令牌给第三方应用程序。 8. 第三方应用程序使用访问令牌向资源服务器请求访问受保护的资源。 9. 资源服务器验证访问令牌的有效性,并根据访问令牌的权限控制对资源的访问。 通过OAuth 2.0,第三方应用程序可以获得用户的授权,以代表用户访问其受保护的资源。这种方式使得用户可以控制第三方应用程序对其资源的访问权限,并增加了用户数据的安全性。 需要注意的是,第三方应用程序需要事先在授权服务器注册,并获得一个客户端ID和客户端密钥。授权服务器和资源服务器之间的交互可以使用不同的授权模式(如授权模式、客户端模式等)来实现。您可以根据具体的需求和实际情况选择合适的授权模式,并按照相应的规范和文档进行配置和集成。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

oh LAN

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值