Restful

Json web token (JWT), 根据官网的定义，是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准（(RFC 7519).该token被设计为紧凑且安全的，特别适用于分布式站点的单点登录（SSO）场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其它业务逻辑所必须的声明信息，该token也可直接被用于认证，也可被加密。 详细介绍可以查看这篇文章 理解JWT（JSON Web Token）认证及实践 JWT 特点 优点 体积小，因而传输速度快 传输方式多样，可以通过URL/POST参数/HTTP头部等方式传输 严格的结构化。它自身（在 payload 中）就包含了所有与用户相关的验证消息，如用户可访问路由、访问有效期等信息，服务器无需再去连接数据库验证信息的有效性，并且 payload 支持为你的应用而定制化。 支持跨域验证，可以应用于单点登录。 存在的问题 JWT 自身（在 payload 中）就包含了所有与用户相关的验证消息，所以通常情况下不需要保存。这种设计存在几个问题： Token不能撤销–客户端重置密码后之前的JWT依然可以使用（JWT 并没有过期或者失效 不支持refresh token，JWT过期后需要执行登录授权的完整流程 无法知道用户签发了几个JWT 针对第一个问题，可能的解决方法有： 保存JWT到数据库（或Redis），这样可以针对每个JWT单独校验 在重置密码等需要作废之前全部JWT时，把操作时间点记录到数据库（或Redis），校验JWT时同时判断此JWT创建之后有没有过重置密码等类似操作，如果有校验不通过 当然，这种解决方法都会多一次数据库请求，JWT自身可校验的优势会有所减少，同时也会影响认证效率。 这篇文章主要介绍解决第二个问题（不支持refresh token）的思路。 refresh token refresh token是OAuth2 认证中的一个概念，和OAuth2 的access token 一起生成，表示更新令牌，过期所需时间比access toen 要长，可以用来获取下一次的access token。 如果JWT 需要添加 refresh token支持，refresh token需要满足的条件有一下几项： 和JWT一起生成返回给客户端 有实效时间，有效时间比JWT要长 只能用来换取下一次JWT，不能用于访问认证 不能重复使用（可选） refresh token 获取流程 refresh token 使用流程 代码示例 import jwt import time # 使用 sanic 作为restful api 框架 def create_token(account_id, username): payload = { "iss": "gusibi.mobi", "iat": int(time.time()), "exp": int(time.time()) + 86400 * 7, "aud": "www.gusibi.mobi", "sub": account_id, "username": username, "scopes": ['open'] } token = jwt.encode(payload, 'secret', algorithm='HS256') payload['grant_type'] = "refresh" refresh_token = jwt.encode(payload, 'secret', algorithm='HS256') return True, { 'access_token': token, 'account_id': account_id, "refresh_token": refresh_token } # 验证refresh token 出否有效 def verify_refresh_token(token): payload = jwt.decode(token, 'secret', audience='www.gusibi.com', algorithms=['HS256']) # 校验token 是否有效，以及是否是refresh token，验证通过后生成新的token 以及 refresh_token if payload and payload.get('grant_type') == 'refresh': # 如果需要标记此token 已经使用，需要借助redis 或者数据库（推荐redis） return True, payload return False, None # 验证token 是否有效 def verify_bearer_token(token): # 如果在生成token的时候使用了aud参数，那么校验的时候也需要添加此参数 payload = jwt.decode(token, 'secret', audience='www.gusibi.com', algorithms=['HS256']) # 校验token 是否有效，以及不能是refresh token if payload and not payload.get('grant_type') == 'refresh': return True, payload return False, None 参考链接 理解JWT（JSON Web Token）认证及实践 理解OAuth 2.0[1] References [1] 理解OAuth 2.0: http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html ...

最近想做个小程序，需要用到授权认证流程。以前项目都是用的 OAuth2 认证，但是Sanic 使用OAuth2 不太方便，就想试一下 JWT 的认证方式。 这一篇主要内容是 JWT 的认证原理，以及python 使用 jwt 认识的实践。 几种常用的认证机制 HUGOMORE42 HTTP Basic Auth HTTP Basic Auth 在HTTP中，基本认证是一种用来允许Web浏览器或其他客户端程序在请求时提供用户名和口令形式的身份凭证的一种登录验证方式，通常用户名和明码会通过HTTP头传递。 在发送之前是以用户名追加一个冒号然后串接上口令，并将得出的结果字符串再用Base64算法编码。例如，提供的用户名是Aladdin、口令是open sesame，则拼接后的结果就是Aladdin:open sesame，然后再将其用Base64编码，得到QWxhZGRpbjpvcGVuIHNlc2FtZQ==。最终将Base64编码的字符串发送出去，由接收者解码得到一个由冒号分隔的用户名和口令的字符串。 优点 基本认证的一个优点是基本上所有流行的网页浏览器都支持基本认证。 缺点 由于用户名和密码都是Base64编码的，而Base64编码是可逆的，所以用户名和密码可以认为是明文。所以只有在客户端和服务器主机之间的连接是安全可信的前提下才可以使用。 接下来我们看一个更加安全也适用范围更大的认证方式 OAuth。 OAuth OAuth 是一个关于授权（authorization）的开放网络标准。允许用户提供一个令牌，而不是用户名和密码来访问他们存放在特定服务提供者的数据。现在的版本是2.0版。 严格来说，OAuth2不是一个标准协议，而是一个安全的授权框架。它详细描述了系统中不同角色、用户、服务前端应用（比如API），以及客户端（比如网站或移动App）之间怎么实现相互认证。 名词定义 Third-party application: 第三方应用程序，又称"客户端"（client） HTTP service：HTTP服务提供商 Resource Owner：资源所有者，通常称"用户"（user）。 User Agent：用户代理，比如浏览器。 Authorization server：认证服务器，即服务提供商专门用来处理认证的服务器。 Resource server：资源服务器，即服务提供商存放用户生成的资源的服务器。它与认证服务器，可以是同一台服务器，也可以是不同的服务器。 OAuth 2.0 运行流程如图： （A）用户打开客户端以后，客户端要求用户给予授权。 （B）用户同意给予客户端授权。 （C）客户端使用上一步获得的授权，向认证服务器申请令牌。 （D）认证服务器对客户端进行认证以后，确认无误，同意发放令牌。 （E）客户端使用令牌，向资源服务器申请获取资源。 （F）资源服务器确认令牌无误，同意向客户端开放资源。 优点 快速开发 实施代码量小 维护工作减少 如果设计的API要被不同的App使用，并且每个App使用的方式也不一样，使用OAuth2是个不错的选择。 缺点： OAuth2是一个安全框架，描述了在各种不同场景下，多个应用之间的授权问题。有海量的资料需要学习，要完全理解需要花费大量时间。 OAuth2不是一个严格的标准协议，因此在实施过程中更容易出错。 了解了以上两种方式后，现在终于到了本篇的重点，JWT 认证。 ...

什么是 RESTful 什么是REST REST（英文：Representational State Transfer，又称具象状态传输）是Roy Thomas Fielding博士于2000年在他的博士论文[1] 中提出来的一种万维网软件架构风格，目的是便于不同软件/程序在网络（例如互联网）中互相传递信息。 REST 的核心是可编辑的资源及其集合，用符合 Atom 文档标准的 Feed 和 Entry 表示。每个资源或者集合有一个惟一的 URI。系统以资源为中心，构建并提供一系列的 Web 服务。 在 REST 中，开发人员显式地使用 HTTP 方法，对系统资源进行创建、读取、更新和删除的操作： 使用 POST 方法在服务器上创建资源 使用 GET 方法从服务器检索某个资源或者资源集合 使用 PUT 方法对服务器的现有资源进行更新 使用 DELETE 方法删除服务器的某个资源 如果一个架构符合REST原则，就可以称它为RESTful架构。 RESTful API 设计定义 以下是几个RESTful API的几个概念。 资源（Resource）：系统上的所有事物都被抽象为资源（一篇文章，一张照片，一段语音） 集合（Collection）：一组资源的合辑称为集合（几篇文章，几张照片） 路径（Endpoint）：路径又称”终点“，表示API的具体网址（每个网址代表一种资源） 那么一个设计良好的RESTful API应该遵循哪些原则呢？ 协议 API与用户的通信协议总是使用HTTPs协议。 域名 应该尽量将API部署在专用域名，例如： https://apis.gusibi.com API地址和版本 在url中指定API版本。比如： https://apis.gusibi.com/v1 以资源为中心设计URL 资源是RESTful API的核心元素，所有的操作都是针对特定资源进化的。而资源就是URL表示的，所以简洁、清晰、结构化的URL设计是至关重要的。 在RESTful 架构中，每个网址代表一种资源（resource），所以网址中不能有动词，只能有名词，而且所用的名词往往与数据库的表格名对应。我们来看一下 Github 的例子： /users/:username/repos /users/:org/repos /repos/:owner/:repo /repos/:owner/:repo/tags /repos/:owner/:repo/branches/:branch 使用正确的Method 对于资源的具体操作类型，使用HTTP method 表示。 以下是常用的HTTP方法。 ...