OAuth2原理与LinkedIn的第三方分享实战

时间  2019-11-07
标签 oauth2 oauth 原理 linkedin 第三方 分享 实战 繁體版
原文   原文链接

OAuth是什么

开放受权（OAuth）是一个开放标准，容许用户让第三方应用访问该用户在某一网站上存储的私密的资源（如照片，视频，联系人列表），而无需将用户名和密码提供给第三方应用。在全世界获得普遍应用，目前的版本是2.0版。html

好比个人应用须要实如今领英上替用户分享一个动态，可是只有获得用户的受权才能在个人应用中调用领英的API进行分享操做，若是直接让用户把用户名密码传到个人应用，确实能够实现，可是有如下问题：git

  • 为了后续的服务，个人应用会保存用户的密码，在个人应用中保存密码很不安全
  • 用户没法限制个人应用中能进行哪些操做
  • 领英必需要有密码登陆的功能，而单纯的密码登陆并不安全
  • 个人应用中还须要处理验证码这样的额外身份验证状况
  • 用户只有修改密码，才能收回权限，但会让全部得到用户受权的第三方应用程序所有失效
  • 只要有一个第三方应用程序被破解，就会致使用户密码泄漏，以及全部被密码保护的数据泄漏

OAuth就是为了解决上面这些问题而诞生的。github

OAuth原理

+--------+                               +---------------+
 |        |--(A)- Authorization Request ->|   Resource    |
 |        |                               |     Owner     |
 |        |<-(B)-- Authorization Grant ---|               |
 |        |                               +---------------+
 |        |
 |        |                               +---------------+
 |        |--(C)-- Authorization Grant -->| Authorization |
 | Client |                               |     Server    |
 |        |<-(D)----- Access Token -------|               |
 |        |                               +---------------+
 |        |
 |        |                               +---------------+
 |        |--(E)----- Access Token ------>|    Resource   |
 |        |                               |     Server    |
 |        |<-(F)--- Protected Resource ---|               |
 +--------+                               +---------------+
复制代码
  • Client：客户端，第三方应用，个人应用就是一个Client
  • Resource Owner ：用户
  • Authorization Server：受权服务器，即提供第三方登陆服务的服务器，如领英
  • Resource Server：服务提供商，一般和受权服务器属于同一应用，如领英

根据上图的信息，咱们能够知道OAuth2的基本流程为：golang

  1. 用户调用第三方应用的功能，如分享，该功能须要使用用户在服务提供商上的权限，因此第三方应用直接重定向到受权服务器的登陆、受权页面等待用户登陆、受权。
  2. 用户登陆以后赞成受权，并返回一个凭证（code）给第三方应用
  3. 第三方应用经过第二步的凭证（code）向受权服务器请求受权
  4. 受权服务器验证凭证（code）经过后，赞成受权，并返回一个服务访问的凭证（Access Token）。
  5. 第三方应用经过第四步的凭证（Access Token）向服务提供商请求相关资源。
  6. 服务提供商验证凭证（Access Token）经过后，将第三方应用请求的资源返回。

简单来讲，OAuth在"客户端"与"服务提供商"之间，设置了一个受权层。"客户端"不能直接登陆"服务提供商"，只能登陆"受权层"，以此将用户与客户端区分开来。"客户端"登陆"受权层"所用的凭证（Access Token），与用户的密码不一样。用户能够在登陆的时候，受权服务器指定受权层令牌的权限范围和有效期。json

LinkedIn的OAuth2交互

下面以在个人应用上实如今领英中替用户分享一个动态为例子，真切地来体验一把OAuth2。浏览器

交互图以下，细节会在下面写到：安全

配置LinkedIn应用程序

除了领英，其余任意开发者平台都须要咱们在平台上注册一个App才能给咱们调用平台API的权限，也方便平台对咱们的资质审核以及调用管理。服务器

因此首先咱们得去领英开发者平台去注册一个App： www.linkedin.com/developer/a…cookie

  • Keys: 完成以后会获得App相关的Key，这是在后续OAuth2交互时须要向领英提供身份验证。
  • 权限：在用户登陆时会给用户展现出个人应用须要哪些权限，个人应用最后调用API的时候会检测权限是否容许。
  • 回调API接口：这是在OAuth2交互时须要验证的一个参数，领英只会与已识别为可信终端的URL进行通讯。

获取用户受权凭证Code

用户在个人应用中点击【分享】按钮，会发送一个GET请求到myApp/linkedin/auth/authorization，其中linkedin/auth/authorization是个人应用里暴露出的一个专门用来进行验证的接口。mvc

个人应用收到请求以后直接回复重定向到领英的受权页面，而且重定向的url中必须包含领英实现的OAuth2的一些参数，以下：

其中state参数是防止csrf攻击加入进来的，关于csrf以及本例中对csrf防范的实现会在文章最后一部分提到。

在go语言+Beego框架中的实现以下：

func (c *AuthorizationController) Get() {
	host := beego.AppConfig.String("host")
	state := util.Generate(10) // random string with length 10
	clientId := beego.AppConfig.String("linkedin_client_id") // 建立app获得的key
	linkedinOauth2AuthorizationUrl := "https://www.linkedin.com/oauth/v2/authorization?response_type=code&client_id=%s&redirect_uri=%s/linkedin/auth/callback&state=%s"
	uri := fmt.Sprintf(linkedinOauth2AuthorizationUrl, clientId, host, state)

	c.SetSession("_csrf_Token", state)
	c.Redirect(uri, 302)
}
复制代码

浏览器跳转到领英页面等待受权

浏览器从上一步中根据重定向url跳转到领英页面，等待用户登陆并受权，若是用户已经登陆就直接跳转，以下图：

用户若是点击Cancel，或者请求因任何其余缘由而失败，则会将其重定向回redirect_uri的URL，并附加一些错误参数。

用户若是点击Allow，用户批准您的应用程序访问其成员数据并表明他们与LinkedIn进行交互，也会将其重定向回redirect_uri，并附加剧要参数code

经过Code拿到Token，并实现分享

redirect_uri就是个人应用中的callback接口，这个接口等待用户传递一个容许受权的凭证code，在个人应用中就能够拿这个code去领英中申请access token，之后就拿着这个access token去访问领英中容许访问的资源了

func (c *CallbackController) Get() {
	// csrf validation
	csrfToken := c.GetSession("_csrf_Token")
	if csrfToken != c.GetString("state") {
		c.Data["json"] = map[string]interface{}{
			"error":             c.GetString("csrf error"),
			"error_description": c.GetString("error_description")}
		c.ServeJSON()
		return
	}

	// user cancel authorization request or linkedin server error
	if c.GetString("error") != "" {
		c.Data["json"] = map[string]interface{}{
			"error":             c.GetString("error"),
			"error_description": c.GetString("error_description")}
		c.ServeJSON()
		return
	}

	// user accept authorization request
	code := c.GetString("code")
	if code != "" {
		// get access token by code
		accessToken := getAccessToken(code)
		// share by access token
		shareResponse := share(accessToken.AccessToken)
		c.Data["json"] = &shareResponse
		c.ServeJSON()
		return
	}
}
复制代码

getAccessToken和share方法仅仅是发送请求到领英的REST API接口，实际上若是领英有golang的sdk的话，就不须要咱们本身使用golang的http包来本身封装请求处理结果了，但惋惜领英并无。

最后给一个GIF图，该图包含了全部的流程展现，从点击【分享】按钮（调用localhost/linkedin/auth/authorization接口）开始：

CSRF

跨站请求伪造(Cross-site request forgery)， 简称为 CSRF，是 Web 应用中常见的一个安全问题。前面的连接也详细讲述了 CSRF 攻击的实现方式。

当前防范 CSRF 的一种通用的方法，是对每个用户都记录一个没法预知的 cookie 数据，而后要求全部提交的请求（POST/PUT/DELETE）中都必须带有这个 cookie 数据。若是此数据不匹配 ，那么这个请求就多是被伪造的。

咱们这里防范CSRF的方法就是经过在用户第一次点击分享时（调用/linkedin/auth/authorization）在Session中存储一个字符串：

func (c *AuthorizationController) Get() {
	...
	c.SetSession("_csrf_Token", state)
	...
}

复制代码

当用户浏览器拿到用户的受权凭证code以后发送给个人应用时（调用/linkedin/auth/callback）检测此时请求中的state与以前在Session中存储的字符串是否相同。

func (c *CallbackController) Get() {
	...
	csrfToken := c.GetSession("_csrf_Token")
	if csrfToken != c.GetString("state") {
		c.Data["json"] = map[string]interface{}{"error": "xsrf error"}
		c.ServeJSON()
		return
	}
	...
}
复制代码

若是相同则能判断是用户的请求，若是不一样，则多是用户点击了其余用户伪造的一个连接发送的请求，从而能够防止code被发送到恶意网站上去

本文资源

代码及部分图片工程文件：github.com/xbox1994/OA…

参考

zh.wikipedia.org/wiki/开放受权
www.ruanyifeng.com/blog/2014/0…
developer.linkedin.com/docs/share-…
zhuanlan.zhihu.com/p/20913727
www.cnblogs.com/flashsun/p/…
beego.me/docs/mvc/co…

91Code-就要编码，关注公众号获取更多内容！

在这里插入图片描述
相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程