阅读 256

试水token认证

从零起步到能实现jwt认证,工作流程:

1 阅读rfc7519

rfc7519是关于jwt的认证协议,jwt有两种实现(jws和jwe),但是jws使用比较广泛,一般默认jwt指jws,jws的组成:

  • header(typ、cty)
  • playload
    • registered claims name,注册声明。是一组预定义的声明,不是强制性的,但推荐使用,常见字段含义:iss(发行者)、sub(主题)、aud(接收者)、exp(到期时间)、iat(发行者)、jti(jwt id)、nbf(什么时候之前不可用)
    • public claim names、private claim names,自行按需定义。
  • signature,用来验证发送者身份,由前两部分加密形成。

使用jwt-go包写了个简单的demo,作用是读jwt-go相关的源码了解包的使用:

package main

import (
   "fmt"
   "github.com/dgrijalva/jwt-go"
   "time"
)

const (
   SECRETKEY = "243223ffslsfsldfl412fdsfsdf" //私钥
)

type CustomClaims struct {
   UserId int64
   jwt.StandardClaims
}
// 忽略错误处理,因为只是个demo
func main() {
   maxAge := 60 * 60 * 24
   customClaims := &CustomClaims{
      UserId: 11,
      StandardClaims: jwt.StandardClaims{
         ExpiresAt: time.Now().Add(time.Duration(maxAge) * time.Second).Unix(),
         Issuer:    "marry",
      },
   }
   // customClaims对应的做法是,先声明一个结构体,然后定义claims
   // 因为声明的结构体包含StandardClaims,所以相当于实现了Claims接口
   // claims1是直接用包里自带的MapClaims类型(而MapClaims已经实现了Cliams接口)
   claims1 := jwt.MapClaims{
      "id":11,
      "name":"mary",
      "exp":time.Now().Add(time.Duration(maxAge)*time.Second).Unix(),
   }
   // new token with sha256
   token := jwt.NewWithClaims(jwt.SigningMethodHS256, customClaims)
   token1 := jwt.NewWithClaims(jwt.SigningMethodHS256, claims1)
   // signature with secret, return string
   tokenString, _ := token.SignedString([]byte(SECRETKEY))
   tokenString1, _ := token1.SignedString([]byte(SECRETKEY))
   fmt.Printf("token: %v\ntoken1: %v\n",tokenString, tokenString1)
   // 解析tokenString
   ret, _ := ParseToken(tokenString)
   ret1, _ := ParseToken(tokenString1)
   fmt.Printf("user: %v\nuser1:%v",ret, ret1)
}

func ParseToken(tokenString string) (*CustomClaims, error) {
   token, err := jwt.ParseWithClaims(tokenString, &CustomClaims{}, func(token *jwt.Token) (i interface{}, err error) {
      if _, ok := token.Method.(*jwt.SigningMethodHMAC); !ok {
         return nil, fmt.Errorf("unexpected signing method: %v", token.Header["alg"])
      }
      return []byte(SECRETKEY), nil
   })
   if claims, ok := token.Claims.(*CustomClaims); ok && token.Valid {
      return claims, nil
   } else {
      return nil, err
   }
}
复制代码

至此,大概了解了jwt的使用流程。

2 阅读rfc6749

rfc6749是关于oauth2.0的规范。在本次作业中用不上,但也是我感兴趣的地方。

2.1 Protocol Flow

这里展示了鉴权中4个角色的交互:

(A)client向resource owner请求授权。该授权请求可以直接发给resource owner,也可以通过authorization server间接进行(例如常见的跳转到授权服务器)。

(B)client获得授权,协议规定了4种授权方式:授权码模式、简化模式、密码模式、客户端模式,github授权第三方使用的是授权码模式,这也是常用的做法,此处不赘述。

(C)client通过authorization grant像authorization server请求token。

(D)authorization server验证client发的grant,如果有效,颁发token。

(E)client通过token向resource server请求资源。

预计(F)resource server验证token,有效则返回相应资源。

规范中ch4-ch9讲的是关于请求和响应的各种规范,比较细节,不赘述。

2.2 github授权第三方登录的demo

写了一个github授权第三方网站登录并获取用户信息的demo,流程是:

  • 先在github注册第三方应用。之后要使用注册的url和重定向url,github生成的clientId和secret。

  • 用户在第三方应用选择github授权登录,浏览器跳转到github登录页面。

  • 用户在github登陆成功。按照设置的重定向url返回第三方应用,此时url上会携带授权码参数code

  • 第三方应用获取授权码,通过授权码向github索取token。

  • github返回token。

  • 第三方应用收到token之后,通过token获取用户信息。

在这里,第三方应用是client,github是resource server,github有自己的authorization serer,用户是resource owner。

3 了解各种token的存储策略

然而了解了上述内容之后,我还是对一个标准的、可应用的sso机制存在问题,尤其是token的存储。虽然jwt有加密和签名,但一旦签名泄漏就和明文没有区别。显然不应当把敏感的信息放在jwt。然而,jwt在微服务中确实是应用广泛。因此,我需要学习各种token的存储机制。

3.1 Postman的鉴权方式

Postman中提及了常用的鉴权方式,因此我去了解各种Authorization type的含义:

  • inherit auth from parent:继承,默认鉴权方式

  • no auth:不鉴权

  • bearer token: 一般也叫jwt==>发送一个json格式的token,服务端针对token校验,粗略地阅了rfc6750。

  • basic token:基础校验,提供用户名密码验证,postman自动生成authorization,是常用的鉴权方式。

  • digest auth: 摘要式认证。在基本身份认证上面扩展了安全性,服务器为每一个连接生成一个唯一的随机数,客户端用这个随机数对密码进行 MD5 加密,然后返回服务器,服务器也用这个随机数对密码进行加密,然后和客户端传送过来的加密数据进行比较,如果一致就返回结果。它是一个二次验证的过程,会有两次认证交互消息。客户端请求资源->服务器返回认证标示->客户端发送认证信息->服务器查验认证。

  • hawk authentication: 另一种认证方案,采用的叫消息码认证算法,和 Digest 认证类似,它也是需要二次交互的

  • aws signature: AWS 签名认证,是针对亚马逊的 AWS 公有云用户签名的认证方式

  • ntlm authentication[beta]: 微软的局域网管理认证协议。

然而,看完这些之后,我的问题依然没有得到解决。于是我去了解github、百度翻译、b站的做法,这里仅说说github。

3.2 github

直接postman访问github的一些url,结果:

eg1:不设置cookie,直接用postman发请求

eg2:

eg3:

相关cookie含义:

  • logged_in:是否登录

  • _octo: This cookie is used by our internal analytics service to distinguish unique users and clients.

  • _gh_sess: This cookie is used for temporary application and framework state between pages like what step the user is on in a multiple step form.

  • _ga: This cookie is used by Google Analytics

  • _device_id: 用于跟踪识别设备

  • tz: 浏览器告知github用户所在的时区

  • user_session: 这个字段用于登录,应该是sessionID

  • _Host-user_session_same_site:设置此cookie是为了确保支持SameSite cookie的浏览器可以检查请求是否来自GitHub。(SameSite-cookies是一种机制,用于定义cookie如何跨域发送。)

  • logged_in: 是否登录

  • dotcom_user: 告知已经登录

  • has_recent_activity: This cookie is used to prevent showing the security interstitial to users that have visited the app recently

4 我的解决策略

至此,可以看出,github采用session-cookie的机制,把鉴权认证相关的内容直接放在了cookie,核心字段是user-session(只要有这个字段就能正常访问,流程是帐号登陆-返回cookie给客户端)。因此,我觉得把token放在cookie是没有问题的。

那么如何设计一套简明可行的sso机制呢?

1 把cookie中的jwt字段置为httpOnly,仅由后端操作

原因:目前比较通用的做法是,不让前端操作敏感的cookie,以防xss攻击。参考github、b站、百度翻译的做法,github的cookie中,只有时区这类非常不敏感的字段才没有置为httpOnly,而b站仅把与session有关的一个字段置为httpOnly,百度翻译算是两者的折衷。所以我认为,是否需要把cookie置为httpOnly,取决于设计者认为这个应用会面临什么类型的风险,需要有多安全。而我认为我们cookie的几个字段说起来都有点敏感,但是真要较真,真正敏感的是token,所以可以仅将token置为httpOnly(这里涉及的代码只会是一些细节。)

2 使用白名单的机制存储token

即,每当用户登录时,颁发一个token,并把token以键值的方式存在redis,每当做token校验时,还需去redis查有没有这个token,有则有效。当用户登出时,从redis删除这个token。

为什么不考虑黑名单?因为黑名单是会膨胀的,而白名单始终存储当前有效的token,整体量不会很大。

3 用rpc和中间件实现主要的鉴权

建立一个简单的鉴权grpc服务,若token未到期、未被修改、存在白名单,即有效。

然而我并没有做grpc部分,不过中间件我倒是写了....

原因:电脑进了半瓶东方树叶....当场变傻,静置之后,刚开电脑以为好了,其实是更严重了...为了各位程序员的头发与心情,喝水要盖盖子...

文章分类
后端
文章标签