摘要:而在这背后则是建立在基础之上。简化模式的授权许可简化模式的授权更加适用于移动端的以及应用,因为他们的安全性并不能够得到保证。除此之外,服务也不会对应用的做唯一性表示验证,依赖回调的地址。
在日常的网站中,我们经常会看见一些来自社交网站的登录按钮,类似使用facebook,twitter登录等。而在这背后则是建立在OAuth基础之上。OAuth2是一套提供授权功能的框架,通过它我们可以使第三方站点获取到我们的用户授权,就像可以拿到facebook 或者微博的用户昵称和头像。OAuth2 提供了包括桌面,web以及移动端应用的授权功能。
授权角色授权一般会定义下面四种身份:
用户
客户端
资源服务器
授权服务器
用户我们通常定义资源的所有者(Resource Owner)即是我们的用户,是他们允许这些应用去访问他们自己的账户信息。当然这些应用所能访问的权限是有限的,它被限制在一个受保护的作用域内(比如只能读取信息,当然这取决于我们自己的设计).
授权服务器和接口服务用户请求授权服务后成功后,会返回一个aceess token给应用,这样应用再访问其他接口服务时候都需要这个凭证.
客户端应用客户端应用既是用户当前所用的这个产品了。它通过它用户授权成功后,可以对用户的一些信息进行访问或者修改,但无论如何,再请求用户信息的时候,我们的api和授权服务必须对它进行合法性验证。
授权流程 应用注册使用授权之前,你必须让这些客户端应用登记在案,你需要它提供一些基本的信息名称比如,应用名称,网站地址,回调地址等等。其中回调地址既是用户完成授权后跳向的地址,在那里应用能够处理我们返回的授权代码以及access tokens.
Cient ID 以及 Client Secret当应用注册完成后,我们会颁布给应用一个授权证书,里面大致记录了客户端的唯一识别(client identifier)和客户端的安全码(client secret).
Client ID 是一串暴漏的字符串,用户构建访问的url以及用于服务器的验证。Client Secret则被用来认证应用的唯一性,从而保证应用和api服务的私秘性。
在前面的流程中,第一步使是获取授权许可和acess token.授权许可的类型取决于用户的请求类型。OAuth 2 定义了下面的四种许可类型,它们试用于不同情形。
授权码,常用于服务端;
简化模式,常用于移动设备上;
用户密码验证,常用于哪些比较信任的服务,比如团队内的项目;
客户端验证,用于应用api访问;
授权码目前大多数服务端的app授权都适用此方式,它会维护一个 client secret。应用通过客户端(比如浏览器)去获取API的授权码;
1.用户会收到一个授权的url,里面大概会带上一些基本信息,比如
client_id(应用id),redirect_uri(回调的地址),response_type(许可类型,类似response_type=code)等
2.用户授权应用,点击链接,用户会进入授权的界面,会需要用户确认接受活着拒绝该应用的授权请求。
3.如果用户点击了确认授权会掉转到回调的url,然后带上授权码。
http://yousite.com?code=AUTHORIZATION_CODE
4.应用获取access_token,应用会请求某个api获取用于访问接口的access_token。
5.应用会接受到接口的响应,获取到access_token,有些应用还会带上refresh_token。
当然拿到access_token后,应用就有权限去访问开放的一些接口,如果接口过期了,则需要重新授权。如果
返回了带有refresh_token,则通过refresh_token可以请求一个新的则需要重新获取新的access_token。
简化模式的授权更加适用于移动端的App以及Web应用,因为他们的安全性并不能够得到保证。同样的也是一个简单的流程,
只是access_token直接返回给客户端,这样access_token会直接暴露给用户,以及设备上的其他应用。除此之外,服务也不会对
应用的做唯一性表示验证,依赖回调的地址。
简化模式的授权不支持 refresh_token!
应用首先会通过一个链接去请求token;
用户点击链接后会跳转到授权的界面,询问用户许可;
用户许可后会直接带上access_token条会到原地址类似下面:
http://yoursite.com?access_token=ACCESS_TOKEN
客户端会将带过来的token保存起来,比如localstorage,cookie;
应用请求其他的api则都会带上这个access_token了。
用户密码验证的形式这个形式就是直接将用户账户和密码拿到后去访问服务,然后拿到access_token,一般这种模式只用于自己的信任的服务,
比如自己家的产品或者桌面应用等。
应用在拿到用户的密码会请求一个地址带上这些数据
http://oauth.api.xxxx.com?username=USERNAME&password=PASSWORD&clientID=1232112
验证成功后,授权服务会返回一个access_token,那么现在这个应用就算授权成功。
客户端验证客户端验证主要是提供一个方式让应用去访问自己的服务账号,去更新一些描述信息或者回调地址等。通过请求一个地址带上自己的信任然后去取得一个access_token.
refresh_token的使用一般access_token都有个时间期限,过期了,访问其他服务则会受限制,这个时候有的会提供一个获取新token的接口,你只需带上refresh_token
以及客户端的其他信息。
理解OAuth 2.0
An Introduction to OAuth 2
The OAuth 2.0 Authorization Framework
hello.js
Thanks ! 图片设计来源于Digital Ocean
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/21580.html
摘要:登录方式本来公司项目是正常的用户名密码登录,但是突然转换成了第三方方式登录,由此开始学习了该种登录形式。同普通的用户名密码登录不同,登录方式中,增加了一个授权层。至此,三方登录已经成功登录。 oAuth2 登录方式 本来公司项目是正常的用户名、密码登录,但是突然转换成了第三方oAuth2方式登录,由此开始学习了该种登录形式。 思路 共有5种授权模式,有授权码模式、简化模式、密码模式、客...
阅读 703·2021-07-25 21:37
阅读 3634·2019-08-30 15:55
阅读 2557·2019-08-30 15:54
阅读 1688·2019-08-30 15:44
阅读 3078·2019-08-30 15:44
阅读 841·2019-08-30 15:43
阅读 1006·2019-08-29 15:36
阅读 3020·2019-08-29 10:58