简述OAuth2.0运作流程

1.什么是OAuth?

  OAUTH是一种开放的协议,为桌面、手机或web应用提供了一种简单的,标准的方式去访问需要用户授权的API服务。

2.为什么会产生OAuth?

  来看一个典型案例:如果一个用户需要两项服务:一项服务是图片在线存储服务A,另一个是图片在线打印服务B。由于服务A与服务B是由两家不同的服务提供商提供的,所以用户在这两家服务提供商的网站上各自注册了两个用户,假设这两个用户名各不相同,密码也各不相同。当用户要使用服务B打印存储在服务A上的图片时,用户该如何处理?方法一:用户可能先将待打印的图片从服务A上下载下来并上传到服务B上打印,这种方式安全但处理比较繁琐,效率低下;方法二:用户将在服务A上注册的用户名与密码提供给服务B,服务B使用用户的账号再去服务A处下载待打印的图片,这种方式效率是提高了,但是安全性大大降低了,服务B可以使用用户的用户名与密码去服务A上查看甚至篡改用户的资源。很多公司和个人都尝试解决这类问题,包括Google、Yahoo、Microsoft,这也促使OAUTH项目组的产生。OAuth目的在于为API访问授权提供一个开放的标准。OAuth规范的1.0版于2007年12月4日发布,2012年10月,OAuth 2.0协议正式发布。

  OAuth是OpenID的一个补充,但是完全不同的服务。OpenID是网站对用户进行认证,让网站知道“你是你所声称的URL的属主”,OAuth其实并不包括认证,只不过“只有认证成功的人才能进行授权”,结果类似于“认证+授权”了。OAuth相当于:A网站给B网站一个令牌,然后告诉B网站说根据这个令牌你可以获取到某用户在A网站上允许你访问的所有信息,如果A网站需要用B网站的用户系统进行登录(学名好像叫federated login),它可以选择OpenID认证,然后通过attribute exchange获取用户的昵称或其他通过OpenID暴露出来的用户属性,或者选择OAuth认证,获取到token后再用token获取用户昵称或其他允许被访问的信息。

3.认证授权过程

  在认证和授权的过程中涉及的三方包括:
    1、服务提供方,用户使用服务提供方来存储受保护的资源,如照片,视频,联系人列表。
    2、用户,存放在服务提供方的受保护的资源的拥有者。
    3、客户端,要访问服务提供方资源的第三方应用,通常是网站,如提供照片打印服务的网站。在认证过程之前,客户端要向服务提供者申请客户端标识。
  使用OAuth进行认证和授权的过程如下所示:
    用户想操作存放在服务提供方的资源。
    用户登录客户端向服务提供方请求一个临时令牌。
    服务提供方验证客户端的身份后,授予一个临时令牌。
    客户端获得临时令牌后,将用户引导至服务提供方的授权页面请求用户授权。在这个过程中将临时令牌和客户端的回调连接发送给服务提供方。
    用户在服务提供方的网页上输入用户名和密码,然后授权该客户端访问所请求的资源。
    授权成功后,服务提供方引导用户返回客户端的网页。
    客户端根据临时令牌从服务提供方那里获取访问令牌。
    服务提供方根据临时令牌和用户的授权情况授予客户端访问令牌。
    客户端使用获取的访问令牌访问存放在服务提供方上的受保护的资源。
  这样看起来是不是有些抽象?接下来将使用github登录网站留言为例,简述OAuth2.0的运作流程。
  假如我有一个网站,你是我网站上的访客,看了文章想留言表示「mark」,留言时发现有这个网站的帐号才能够留言,此时给了你两个选择:一个是在我的网站上注册拥有一个新账户,然后用注册的用户名来留言;一个是使用 GitHub 帐号登录,使用你的 github 用户名来留言。前者你觉得过于繁琐,于是惯性地点击了 GitHub 登录按钮,此时 OAuth 认证流程就开始了。需要明确的是,即使用户刚登录过 GitHub,我的网站也不可能向 GitHub发一个什么请求便能够拿到访客信息,这显然是不安全的。就算用户允许你获取他在 GitHub上的信息,GitHub为了保障用户信息安全,也不会让你随意获取。所以操作之前,我的网站与 GitHub之间需要要有一个协商。
  1. 网站和 GitHub之间的协商
  GitHub会对用户的权限做分类,比如读取仓库信息的权限、写入仓库的权限、读取用户信息的权限、修改用户信息的权限等等。如果我想获取用户的信息,GitHub会要求我,先在它的平台上注册一个应用,在申请的时候标明需要获取用户信息的哪些权限,用多少就申请多少,并且在申请的时候填写你的网站域名,GitHub只允许在这个域名中获取用户信息。此时我的网站已经和 GitHub之间达成了共识,GitHub也给我发了两张门票,一张门票叫做 Client Id,另一张门票叫做 Client Secret。
  2. 用户和 GitHub之间的协商
  用户进入我的网站,点击 GitHub登录按钮的时候,我的网站会把上面拿到的 Client Id 交给用户,让他进入到 GitHub的授权页面,GitHub看到了用户手中的门票,就知道这是我的网站让他过来的,于是它就把我的网站想要获取的权限摆出来,并询问用户是否允许我获取这些权限。

猜你喜欢

转载自www.cnblogs.com/zlnevsto/p/8716489.html