目录
一,什么是OAuth2
OAuth2.0 是目前使用非常广泛的授权机制,用于授权第三方应用获取用户的数据。用户可以通过选择其他登录方式来使用 gitee ,这里就使用到了第三方认证。OAuth 引入了一个授权层,用来分离两种不同的角色:客户端和资源所有者。 ...... 资源所有者同意以后,资源服务器可以向客户端颁发令牌。客户端通过令牌,去请求数据。
二,OAuth2中的角色
1. 资源所有者(本人)能够授予对受保护资源的访问权限的实体,如果资源的所有者为个人,也被成为最终用户2. 资源服务器(APP)存储有受保护资源的服务器, 能够接受并验证访问令牌,并响应受保护资源的访问请求简单的说就是图片上所标记的地方3. 客户(被授权的网站)需要被授权,然后再访问受保护资源的实体。客户这个术语,并不是特指应用程序,服务器,计算机 等。4. 授权服务器(指OAuth2)验证资源所有者并获取授权成功后,向客户发出访问令牌
三,认证流程
解释说明:
Client相当于正在使用的小程序
Resource Owner相当于本人的微信账号
Authorization Server相当于OAuth2
Resource Server 相当于微信
当使用者选择微信登入某小程序,小程序就会发送请求给使用者的微信账号,当使用者点击允许后,小程序拿到允许授权后就会将授权信息发送至OAuth2(也就是认证服务器),然后认证服务器得到信息后就会发送一个Token令牌给小程序,小程序在拿着这个Token令牌去请求微信,微信就会找到使用者的微信账号得知使用者已同意,然后微信就会允许小程序的一个登入。
四,令牌的特点
使用令牌方式的优点:(1)令牌又时效性,一般是短期的,且不能修改,密码一般是长期有效的(2)令牌可以由颁发者撤销,且即时生效,密码一般可以不用修改而长期有效(3)令牌可以设定权限的范围,且使用者无法修改在使用令牌时需要保证令牌的保密,令牌验证有效即可进入系统,不会再做其他的验证。
五,四种认证方式
由于互联网有多种场景, OAuth2 定义了四种获取令牌的方式,可以选择合适与自己的方式(1)授权码( authorization-code )(2)隐藏式( implicit )(3)密码式( password ):(4)客户端凭证( client credentials )
授权码
第三方应用先申请一个授权码,然后再用该码获取令牌。最常见的用法,安全性高,适合 web 应用。 授权码通过前端传送,令牌则是储存在后端,而且所有与资源服务器的通信都在后端完成。这样的前后端分离,可以避免令牌泄漏。流程如下:就是以上提到的
1. 资源服务器提供一个链接,用户点击后就会跳转到认证服务器,授权用户数据给资源服务器使用,资源服务器提供的连接的示例:https://b.com/oauth/authorize? response_type=code& client_id=CLIENT_ID& redirect_uri=CALLBACK_URL& scope=read
response_type=code,表示使用授权码方式client_id=CLIENT_ID,请求者的身份IDscope=readredirect_uri=CALLBACK_URL, 认证服务器接受请求之后的调转连接,可以根据这个连接将生成 的code发送给资源服务器scope=read,授权范围为只读2. 页面跳转后,用户登录认证服务器,同意或拒绝资源服务器的授权请求,认证服务器根据上一步的redirect_uri 地址,将生成的授权码返回给资源服务器。https://resouce.com/callback_url?code=AUTHORIZATION_CODE
code 返回的认证码3. 客户拿到认证码之后,向认证服务器发给请求,申请令牌https://b.com/oauth/token? client_id=CLIENT_ID& client_secret=CLIENT_SECRET& grant_type=authorization_code& code=AUTHORIZATION_CODE& redirect_uri=CALLBACK_URL
client_id 资源服务器的身份 IDclient_secret=CLIENT_SECRET 安全参数,只能在后端发请求grant_type=authorization_code 表示授权的方式为授权码code=AUTHORIZATION_CODE 用来获取令牌的授权码redirect_uri=CALLBACK_URL 令牌生成后的颁发地址4. 认证服务器对授权码进行认证,通过后颁发令牌,{ "access_token":访问令牌, "token_type":"bearer", "expires_in":过期时间, "refresh_token":"REFRESH_TOKEN", "scope":"read", "uid":用户ID, "info":{...} }
隐藏方式
隐藏方式合适的场景:当 web 应用为纯前端应用没有后端,此时必须将令牌放在前端保存,省略了申请授权码的步骤1. 资源服务器提供连接,跳转到认证服务器https://b.com/oauth/authorize? response_type=token& client_id=CLIENT_ID& redirect_uri=CALLBACK_URL& scope=read
2. 用户需要在认证服务器登录,并进行授权, 授权成功后会根据第一步提供的 CALLBACK_URL 地址 返回生成的token
这种方式的特点:这种方式不安全,适用于对安全性不高的场景,令牌的有效期一般设置的比较短,通常是会话期间有效,浏览器关闭令牌就时效了
密码方式
非常信任某个应用,将用户名和密码直接告诉应用,应用拿到用户名和密码后直接申请令牌1. 资源服务器要求用户提供认证服务器的用户名和密码,拿到以后资源服务器向认证服务器申请令牌https://oauth.b.com/token? grant_type=password& username=USERNAME& password=PASSWORD& client_id=CLIENT_ID
grant_type=password 认证方式username=USERNAME 用户名password=PASSWORD 密码client_id=CLIENT_ID 客户 id2. 认证服务器验证身份通过后,直接在响应中发放令牌,资源服务器在响应中获取令牌。
凭证方式
这种方式适用于没有前端的命令行应用,通过命令行的方式请求令牌1. 资源服务器使用命令行向认证服务器发送请求https://oauth.b.com/token? grant_type=client_credentials& client_id=CLIENT_ID& client_secret=CLIENT_SECRET
grant_type=client_credentials 凭证方式client_id=CLIENT_ID 客户身份 IDclient_secret=CLIENT_SECRET 认证码该方式真对的是第三方应用,而不是用户,可以多个用户共享一个令牌