网站没收录,在家自己做网站,建设工程规范下载网站,国家工商企业查询#x1f389;#x1f389;欢迎来到我的CSDN主页#xff01;#x1f389;#x1f389; #x1f3c5;我是Java方文山#xff0c;一个在CSDN分享笔记的博主。#x1f4da;#x1f4da; #x1f31f;推荐给大家我的专栏《OAuth 2》。#x1f3af;#x1f3af; #x1… 欢迎来到我的CSDN主页 我是Java方文山一个在CSDN分享笔记的博主。 推荐给大家我的专栏《OAuth 2》。 点击这里就可以查看我的主页啦 Java方文山的个人主页 如果感觉还不错的话请给我点赞吧 期待你的加入一起学习一起进步 一、OAuth2的简介
1.什么OAuth2
OAuth 2 是一种授权框架允许第三方应用通过用户授权的形式访问服务中的用户信息最常见的场景是授权登录再复杂一点的比如第三方应用通过 Github 给开发者提供的接口访问权限内的用户信息或仓库信息。OAuth2 广泛应用于 web 、桌面应用、移动 APP 的第三方服务提供了授权验证机制以此实现不同应用间的数据访问权限。 下面分别从不同角色、授权类型、使用场景及流程的纬度详细介绍 OAuth2 2.OAuth Roles
OAuth 定义了四种角色
资源拥有者 (Resource Owner)客户端 (Client)资源服务器 (Resource Server)授权服务器 (Authorization Server)
资源拥有者其实就是真实的用户用户授权给第三方应用访问在其他系统的用户信息。第三方应用访问授权用户的信息范围 scope 属于申请接入服务时选择的权限之内(例如读或写访问权限)
资源服务控制用户的信息授权服务验证用户提供的信息是否正确并返回 access token 给第三方应用。 站在第三方开发者的角度看被接入的系统提供的服务 API 同时实现了资源和授权角色。在这里把资源服务端和授权服务端统一为“服务角色或 API 角色”。
客户端就是要求接入的第三方应用获取用户在提供服务的系统的账户信息。对于客户端而言最终获取到用户在服务端的账户信息首先需要用户授权用户授权后传给提供服务端验证成功之后返回 access token 在通过 access token 请求提供服务的系统在这里我们成为 API 下文也是获取用户在 API 中的账户信息。
3.授权流程
接下来文中提到的客户端均为第三方应用服务端均为被接入的服务。譬如拉勾网有微博登录功能那么拉勾网就是客户端微博就是服务端。 刚刚解释了 OAuth 系统中角色的概念接下来可以解释整个授权的流程。 流程图解释
用户点击客户端提供的授权请求客户端请求服务的授权页面呈现给用户用户点击确认授权后服务端返回授权许可凭证给客户端客户端通过步骤二接收到的授权许可凭证及在服务端注册的应用信息请求服务端如果步骤三验证通过服务端则返回 access token 给客户端客户端通过第四步获取的 access token 请求服务端获取资源如果服务端校验 access token 成功则返回指定资源给客户端
以上步骤是 OAuth2 授权登录的步骤当然不同类型的授权许步骤会不一样下文会详细逐一讨论。 二、第三方应用创建
第三方接入某平台的 OAuth 2 服务之前通常需要在平台提供的注册网站通常叫做 developer or API新建一个应用注册成功之后平台会生成应用的 ID 和密码。 读者可以访问 Github 的开发中心看看国内写的规范的有 coding developer
在平台的注册页面至少得提供如下信息
应用名称应用网址回调链接
回调域名的作用用户点击同意按钮之后服务端向客户端返回授权码或 access token ,当然如果是禁止操作也需回调告知客户端结果。
在 OAuth 2 服务提供平台新建一个应用之后平台会提供一对客户端 ID 和密码作为客户端凭证。客户端 ID 是可以公开的字符串用以构建授权请求链接用户授权之后客户端使用服务端的授权码和平台分配的密码获取 access token 。密码应当妥善保管以免泄漏。 1.授权许可
在第一张授权流程图中前四步包含了获取授权许可获取 access token ,授权许可有四种类型服务端返回哪种类型取决于客户端在请求链接中构建的 response_type 参数。四种类型的授权许可有不同的应用场景
授权码通过授权码服务端通过 Ajax 把 access token 返回给客户端隐式用于移动 APP 或 web 应用应用运行在用户的设备上用户密码凭证同一个公司不同系统之间内部账户互联互通比如国内某社区的代码托管系统通过社区的账户也可以登录。客户端凭证第三方应用自身服务访问提供 OAuth2 服务提供的平台资源 1.1.授权码 (Grant Type: Authorization Code)
授权码是 OAuth2 授权最广泛的方式得益于平台给第三方应用分配的 ID 和密码都是隐藏在第三方应用的后端代码中。因为授权码是基于重定向的方式要想使用授权码的方式第三方应用必须能够调用用户系统中的应用譬如浏览器、和提供一个接口接收平台服务的回调获取授权码。 一步步解释授权码的流程图
步骤一构建获取授权码请求链接
下文提到的例子都是基于 digiterocean 的 OAuth2 第一步是构建一个请求 Auth Server 获取授权码的链接向服务端发起请求
https://cloud.digitalocean.com/v1/oauth/authorize?response_typecodeclient_idCLIENT_IDredirect_uriCALLBACK_URLscoperead分解请求链接
https://cloud.digitalocean.com/v1/oauth/authorize 表示服务端授权 endpointclient_id 平台分配给第三方应用的 IDredirect_uriCALLBACK_URL 第三方开发者在平台新建第三方应用时填写的回调 URLresponse_typecode 指定服务端返回授权码scoperead 指定第三方应用请求权限类型
步骤二用户授权给第三方应用
当用户点击第一步构建的链接之后在用户已经登录服务端之后才能点击确认授权譬如想通过微信登录某个第三方网址你必须首先已经登录微博。这是平台会给用户提供一个页面给用户确认是否授权。 步骤三服务端给客户端返回授权码
当用户点击同意授权之后服务端发起一个请求重定向到第三方平台填写的回调链接且请求链接中同时包含了服务端生成的授权码。
https://dropletbook.com/callback?codeAUTHORIZATION_CODE步骤四第三方应用请求服务端获取 access token
客户端获取到服务端返回的授权码之后接着使用授权码和平台分配的密码请求服务端获取服务端的 access token 。第三方应用后端代码拼接的 URL 格式形似
https://cloud.digitalocean.com/v1/oauth/token?client_idCLIENT_IDclient_secretCLIENT_SECRETgrant_typeauthorization_codecodeAUTHORIZATION_CODEredirect_uriCALLBACK_URL在这里需注意两个参数其一是 client_secret 没有暴露出去在第三方应用后端代码中拼接请求链接另一是 redirect_uri 这里不是在平台新建应用时填写的回调链接而是第三方应用已经实现的另一个 action 处理服务端返回 access token 的请求。
步骤五第三方应用接收 access token
如果第四部客户端发送的信息被服务端校验成功服务端则返回 access token 有一些平台同时也同时传递 refresh token 。返回的 json 信息形似
{
access_token:ACCESS_TOKEN,
token_type:bearer,
expires_in:2592000,
refresh_token:REFRESH_TOKEN,
scope:read,
uid:100101,
info:{name:Mark E. Mark,email:markthefunkybunch.com}
}至此已经走完 oauth 2 授权码的方式所有流程。在 access_token 没有失效的前提下可通过 access_token 可以访问平台服务端提供的资源。另外如果还提供了 refresh_token 在 access_token 失效的情况下可以通过 refresh_token 再次去获取有效的 access_token 。 1.2.隐式 (Grant Type: Implicit)
相比授权码的授权许可这种后端实现隐式授权类型在应用于前端实现移动客户端或者浏览器其缺陷就是并不保证平台分配给第三方平台的密码凭证足够安全。隐式授权同样也是基于重定向的方式但是 access_token 通过网页重定向返回给第三方平台而不是通过接口调用的方式 暴露了 access_token 在重定向链接中这点和授权码不同。另外也不支持服务端校验客户端第三方应用密码只是依赖在平台新建应用是填写的回调链接。
隐式授权不支持 refresh_token
授权大概流程如下用户请求授权同意授权后服务端把 access_token 拼接到回调链接上通过浏览器重定向到客户端然后客户端获取到 access_token 。 通过流程图可看出在第三步和授权码不同的是服务端重定向到网页而不是通过接口把 access_token 返回给客户端。
步骤一构建隐式授权请求链接
与授权码的步骤一差不多一致只是 response_type 字段的参数值为 token
步骤二用户授权给第三方
与授权码授权的步骤二完全一致
步骤三通过服务端重定向链接User-agent (浏览器或者 APP) 获取 access_token
与授权码不同的是用户点击授权之后服务端通过把 access_token 通过网页重定向到回调链接客户端通过重定向链接才能获取到access_token 而授权码获取 access_token是通过服务端通过 ajax 请求的形式直接访问第三方应用的后端接口把 access_token传给第三方后端。
步骤三前端根据重定向调整
前端浏览器重定向请求第三方平台的后端
步骤五第三方应用后端通过脚本获取在重定向链接中的 access_token
第三方应用后端通过脚本获取在重定向链接上的 access_token
步骤六User-Agent 执行第三方应用后端返回的脚本把 access_token 返回给第三方平台后端。 1.3用户密码凭证
用户直接给第三方应用提供在提供服务端账号密码获取服务端的 access_token。这种授权方式常用于一个企业不同服务之间的账号互联互通。 用户给第三方应用提供账号密码之后客户端发送 POST 请求给服务端获取access_token
https://oauth.example.com/token?grant_typepasswordusernameUSERNAMEpasswordPASSWORDclient_idCLIENT_ID如果服务端校验客户端第三方应用传过来的账户密码正确则把 access_token返回给客户端用户授权完成。 1.4.客户端凭证
这种授权方式常用于第三方应用想要更改自身在服务提供方注册的应用信息比如更改应用描述或回调链接地址。
第三方应用通过发送服务端分配的 ID 和密码给后端校验POST 的 URL 格式形似
https://oauth.example.com/token?grant_typeclient_credentialsclient_idCLIENT_IDclient_secretCLIENT_SECRETAccess Token 和 Refresh Token
第三方应用从服务提供平台获取到有效的 access_token 之后即可根据平台提供的接口访问服务端的资源。
curl -X POST -H Authorization: Bearer ACCESS_TOKENhttps://api.digitalocean.com/v2/$OBJECT如果服务提供平台支持 refresh_token 那么第三方应用的 access_token 失效之后可通过 refresh_token 再次获取有效的 access_token
例如 digitalocean 支持第三方应用通过 POST 请求再此获取有效的 access_token
https://cloud.digitalocean.com/v1/oauth/token?grant_typerefresh_tokenclient_idCLIENT_IDclient_secretCLIENT_SECRETrefresh_tokenREFRESH_TOKEN
到这里我的分享就结束了欢迎到评论区探讨交流
如果觉得有用的话还请点个赞吧
