天游线路检测登录

说说OAuth那点事

  今年年初,第一份实习,接触了如何使用Facebook API, Twitter API...去获取数据,自动发个Facebook什么的,也在那会听到了这个词-OAuth. 不明觉厉。无奈最近实习中又接触了,实在不想迷迷糊糊了,决心搞清楚,在拜读了各路大牛的文章之后,决定为自己写个总结。

  OAuth 1.0 协议过于复杂,易用性差,所以并没有得到普及,下文中给出了授权的流程图,可以简单了解了解,现在很少有用的了。

  先来说一个场景:比如你第一次打开简书官网,想要注册一个账号。你会看到简书允许你通过新浪微博账号登陆。当你点击之后,需要你登陆微博。之后会出现“是否同意简书获取你的个人信息”等等,如果你选择授权,之后会跳转回简书。你会发现你在简书的用户名就是你微博的用户名。然后,你会发出一条新的微博比如“我加入了简书,一个基于内容分享的社区!”(这只是举个例子,不知道简书有没有这样做)。

  资源拥有者其实就是用户(user),用户将会授权一个第三方应用可以获取他们的账户资源。当然第三方应用程序对于用户账户的操作是有限制的(比如,read access, read and write access)!这个限制就是用户授权时给予的权限范围(scope)

  上面场景中,微博账户就是资源拥有者。read access就比如读取微博用户名,write access就比如以你的名义发了一个微博。

  资源服务器与授权服务器可以是同一台服务器,这里分开主要是便于解释清楚OAuth协议。从程序开发者的角度,这两个都是services API会执行的事情。

  在了解完OAuth中的四个角色之后,我们看看这四个角色之间是如何互动的。下面是基本运行流程。

  对于一个应用程序来说,如果它想要使用OAuth,那么首先它要在服务提供商那里注册。一般出现在网站的“developer”或者“API”部分。

  在用户同意授权(或者拒绝)之后,服务提供商会将用户重新导向这个Callback URL,这个Callback URL要来负责处理授权码或者访问令牌。

  应用程序注册完成之后,服务提供商会颁发给应用程序一个“客户端认证信息(client credentials)”。Client Credential包括:

  用户点击上述URI之后,用户首先要登陆,证明其身份。然后选择同意授权应用程序可以访问他们的账户或者拒绝。

  如果用户同意授权,服务提供商会将用户代理重定向到第一步中的redirect_uri,并且会包含授权码。

  隐式授权模式主要用于客户端应用程序(client-side application),比如手机应用、桌面客户端应用程序和运行于浏览器上的web应用程序。

  因为没有server端,client secret的保密性不能得到保证。授权令牌给予用户代理(比如,浏览器),再由用户代理交给应用程序。所以用户设备上的其他应用程序同样可以得到授权令牌。

  用户点击上述URI之后,用户首先要登陆,证明其身份。然后选择同意授权应用程序可访问他们的账户或者拒绝。

  假设用户同意授权,授权服务器重定向用户代理到第一步提到的redirect_uri。并在URI fragment中包含授权令牌(但不能查看)。

  用户代理依照重定向的指令,向资源服务器发出请求,但并不包含上一步中得到的授权令牌(#后面的部分)。用户代理将完整的重定向URI保存在本地。

  资源服务器会返回一个网页(通常是一个HTML文件内嵌一段脚本)。这段内嵌的脚本(script)可以访问第三步中用户代理保存在本地的完整的重定向URI,并从中提取授权令牌。

  比如应用程序想要修改自身注册信息或者redirect URI。又或者想要获取资源服务器中不与具体用户相关的信息。比如一个应用程序想要获取新浪微博中含有#happy的微博。

  应用程序向授权服务器提供自身认证信息(client ID和client secret),并请求授权令牌。

  Spring Cloud为开发人员提供了快速构建分布式系统中一些常见模式的工具(例如配置管理,服务发现,断路器,智...

  本文以一种简化的格式描述OAuth 2.0 ,以帮助开发人员和服务提供者实现该协议。 The OAuth 2 sp...

  1. 微服务架构介绍 1.1 什么是微服务架构? 形像一点来说,微服务架构就像搭积木,每个微服务都是一个零件,并使...

上一篇:从员工角度对创业老板的建议

下一篇:没有了