token 小记

最近了解下基于 Token 的身份验证,跟大伙分享下。很多大型网站也都在用,比如 Facebook,Twitter,Google+,Github 等等,比起传统的身份验证方法,Token 扩展性更强,也更安全点,非常适合用在 Web 应用或者移动应用上。Token 的中文有人翻译成 “令牌”,我觉得挺好,意思就是,你拿着这个令牌,才能过一些关卡。

传统身份验证的方法

HTTP 是一种没有状态的协议,也就是它并不知道是谁是访问应用。这里我们把用户看成是客户端,客户端使用用户名还有密码通过了身份验证,不过下回这个客户端再发送请求时候,还得再验证一下。

解决的方法就是,当用户请求登录的时候,如果没有问题,我们在服务端生成一条记录,这个记录里可以说明一下登录的用户是谁,然后把这条记录的 ID 号发送给客户端,客户端收到以后把这个 ID 号存储在 Cookie 里,下次这个用户再向服务端发送请求的时候,可以带着这个 Cookie ,这样服务端会验证一个这个 Cookie 里的信息,看看能不能在服务端这里找到对应的记录,如果可以,说明用户已经通过了身份验证,就把用户请求的数据返回给客户端。

上面说的就是 Session,我们需要在服务端存储为登录的用户生成的 Session ,这些 Session 可能会存储在内存,磁盘,或者数据库里。我们可能需要在服务端定期的去清理过期的 Session 。

基于 Token 的身份验证方法

使用基于 Token 的身份验证方法,在服务端不需要存储用户的登录记录。大概的流程是这样的:

  1. 客户端使用用户名跟密码请求登录
  2. 服务端收到请求,去验证用户名与密码
  3. 验证成功后,服务端会签发一个 Token,再把这个 Token 发送给客户端
  4. 客户端收到 Token 以后可以把它存储起来,比如放在 Cookie 里或者 Local Storage 里
  5. 客户端每次向服务端请求资源的时候需要带着服务端签发的 Token
  6. 服务端收到请求,然后去验证客户端请求里面带着的 Token,如果验证成功,就向客户端返回请求的数据

JWT

实施 Token 验证的方法挺多的,还有一些标准方法,比如 JWT,读作:jot ,表示:JSON Web Tokens 。JWT 标准的 Token 有三个部分:

  • header
  • payload
  • signature

中间用点分隔开,并且都会使用 Base64 编码,所以真正的 Token 看起来像这样:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJuaW5naGFvLm5ldCIsImV4cCI6IjE0Mzg5NTU0NDUiLCJuYW1lIjoid2FuZ2hhbyIsImFkbWluIjp0cnVlfQ.SwyHTEx_RQppr97g4J5lKXtabJecpejuef8AqKYMAJc

Header

header 部分主要是两部分内容,一个是 Token 的类型,另一个是使用的算法,比如下面类型就是 JWT,使用的算法是 HS256。

{
  "typ": "JWT",
  "alg": "HS256"
}

上面的内容要用 Base64 的形式编码一下,所以就变成这样:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

Payload

Payload 里面是 Token 的具体内容,这些内容里面有一些是标准字段,你也可以添加其它需要的内容。下面是标准字段:

  • iss:Issuer,发行者
  • sub:Subject,主题
  • aud:Audience,观众
  • exp:Expiration time,过期时间
  • nbf:Not before
  • iat:Issued at,发行时间
  • jti:JWT ID

比如下面这个 Payload ,用到了 iss 发行人,还有 exp 过期时间。另外还有两个自定义的字段,一个是 name ,还有一个是 admin 。

{
 "iss": "ninghao.net",
 "exp": "1438955445",
 "name": "wanghao",
 "admin": true
}

使用 Base64 编码以后就变成了这个样子:

eyJpc3MiOiJuaW5naGFvLm5ldCIsImV4cCI6IjE0Mzg5NTU0NDUiLCJuYW1lIjoid2FuZ2hhbyIsImFkbWluIjp0cnVlfQ

Signature

JWT 的最后一部分是 Signature ,这部分内容有三个部分,先是用 Base64 编码的 header.payload ,再用加密算法加密一下,加密的时候要放进去一个 Secret ,这个相当于是一个密码,这个密码秘密地存储在服务端。

  • header
  • payload
  • secret
var encodedString = base64UrlEncode(header) + "." + base64UrlEncode(payload);
HMACSHA256(encodedString, ‘secret‘);

处理完成以后看起来像这样:

SwyHTEx_RQppr97g4J5lKXtabJecpejuef8AqKYMAJc

最后这个在服务端生成并且要发送给客户端的 Token 看起来像这样:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJuaW5naGFvLm5ldCIsImV4cCI6IjE0Mzg5NTU0NDUiLCJuYW1lIjoid2FuZ2hhbyIsImFkbWluIjp0cnVlfQ.SwyHTEx_RQppr97g4J5lKXtabJecpejuef8AqKYMAJc

客户端收到这个 Token 以后把它存储下来,下回向服务端发送请求的时候就带着这个 Token 。服务端收到这个 Token ,然后进行验证,通过以后就会返回给客户端想要的资源。

相关链接

时间: 2024-08-01 00:57:24

token 小记的相关文章

Gitlab Merge Request Builder Plugin 配置小记

以前在给一些开源项目贡献代码的时候,在github上一提交pull request或者提交的分支代码更新了的时候,jenkins就会自动把代码进行merge并且运行单元测试,当时看了心里就2个字: NB! 那个时候心里就想,啥时候我也得弄这么一个高大上的玩意儿.随着 gitlab 在工作中的逐渐使用,这个想法越来越强烈.上周末搜来搜去,发现jenkins还真有一款针对gitlab的merge request的插件:Gitlab Merge Request Builder Plugin 当时就心痒

八幅漫画理解使用 JSON Web Token 设计单点登录系统

原文出处: John Wu 上次在<JSON Web Token – 在Web应用间安全地传递信息>中我提到了JSON Web Token可以用来设计单点登录系统.我尝试用八幅漫画先让大家理解如何设计正常的用户认证系统,然后再延伸到单点登录系统. 如果还没有阅读<JSON Web Token – 在Web应用间安全地传递信息>,我强烈建议你花十分钟阅读它,理解JWT的生成过程和原理. 用户认证八步走 所谓用户认证(Authentication),就是让用户登录,并且在接下来的一段时

Android 编译错误——布局 Error parsing XML: not well-formed (invalid token)

在修改了Android布局文件后,编译出现Error parsing XML: not well-formed (invalid token). 首先先排查xml文件的编码格式是否为UTF-8, <?xml version="1.0" encoding="utf-8"?> ,注意,从别处copy的要留意编码格式! 还有各个标签是否有遗漏,把鼠标箭头移到出错误的layout上 点击鼠标右键选择Source然后再选Format. 都没有问题,结果发现报错处(

SpringBoot - 二零一七0421小记

一.SpringBoot使用起来比起SpringMVC更便捷,在注解上的小变化,我记录了下面几个: @Controller + @ResponseBody = SpringMVC中用@RestController来代替前面两个注解,通过这个注解,可以将所有的前端http请求放入SpringBoot的Controller容器中,并返回json格式的数据给前端 @RequestMapping(value={"/hello","/hi"},method=RequestMe

WebApi基于Token和签名的验证

最近一段时间在学习WebApi,涉及到验证部分的一些知识觉得自己并不是太懂,所以来博客园看了几篇博文,发现一篇讲的特别好的,读了几遍茅塞顿开(都闪开,我要装逼了),刚开始读有些地方不理解,所以想了很久,因此对原文中省略的部分这里做一点个人的理解和补充,非常基础,知道的园友就不需要了,只是帮助初次学习的园友理解.原文传送门: http://www.cnblogs.com/MR-YY/p/5972380.html#!comments 本篇博文中的所有代码均来自上述链接,如果你觉得有帮助,请点击链接给

Retrofit Token过期自动刷新并重新请求接口

在有心课堂的群里,有网友提出如下场景: 当前开发的 App 遇到一个问题: 当请求某个接口时,由于 token 已经失效,所以接口会报错. 但是产品经理希望 app 能够马上刷新 token ,然后重复请求刚才那个接口,这个过程对用户来说是无感的. 请求 A 接口->服务器返回 token 过期->请求 token 刷新接口->请求 A 接口 我们应该是怎么解决这个问题呢? 经过百度搜索到了相关信息,这里总结下. 本文是采用RxJava + Retrofit来实现网络请求封装. 实现原理

使用 AngularJS &amp; NodeJS 实现基于 token 的认证应用(转)

认证是任何 web 应用中不可或缺的一部分.在这个教程中,我们会讨论基于 token 的认证系统以及它和传统的登录系统的不同.这篇教程的末尾,你会看到一个使用 AngularJS 和 NodeJS 构建的完整的应用. 一.传统的认证系统 在开始说基于 token 的认证系统之前,我们先看一下传统的认证系统. 用户在登录域输入 用户名 和 密码 ,然后点击 登录 : 请求发送之后,通过在后端查询数据库验证用户的合法性.如果请求有效,使用在数据库得到的信息创建一个 session,然后在响应头信息中

Docker Registry v2 + Token Auth Server (Registry v2 认证)实例。

关于Registry 对于registry v1 --> v2中,其中的原理.优化等,这里不再做一一介绍.这里有篇文章我瞄过几眼应该是比较不错的介绍文章了:http://dockone.io/article/747 . Registry v2 token机制 官方document:https://docs.docker.com/registry/spec/auth/token/ 目前docker registry v2 认证分为以下6个步骤: 1. docker client 尝试到regist

广州postgresql用户会技术交流会小记 2015-9-19

广州postgresql用户会技术交流会小记  2015-9-19 今天去了广州postgresql用户会组织的技术交流会 分别有两个session 第一个讲师介绍了他公司使用postgresql -X2的情况 第二个讲师介绍了postgresql里面的一些执行计划分析 我个人比较关注第一个session,因为涉及到真正的应用案例 网上有对postgresql -X2的简短介绍,我先转载过来 转载:http://francs3.blog.163.com/blog/static/405767272