Web API接口鉴权方式

这篇具有很好参考价值的文章主要介绍了Web API接口鉴权方式。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

一、什么是鉴权?为什么要鉴权

鉴权(authentication),也叫做认证,即验证用户是否拥有访问系统的权利。

HTTP本身是无状态的请求,每次请求都是一次性的,并不会知道请求前后发生了什么。但在很多情况情况下都需要维护状态,最典型的就是用户登录系统,并在系统中进行一系列操作

API接口直接暴露在互联网上是存在安全风险的,如果不进行鉴权,就有可能被网上的不法分子恶意攻击(如:爬虫,恶意访问等),使得api资源被非法访问占用,正常用户访问受阻。因此鉴权十分必要,只有鉴权成功的请求才能请求服务,否则就被拦截
接口鉴权,网络,API鉴权,Web,cookie,ak/sk,OAuth2.0

二、Cookie/Session鉴权

为每个用户颁发一个身份牌

为了识别用户,可以为每个用户设置一个“身份牌”,“身份牌”里面可以存放用户的信息,每次请求的时候都带上这个“身份牌”,这样就可以用来识别用户了。而这个“身份牌”就是我们经常提到的“cookie”
接口鉴权,网络,API鉴权,Web,cookie,ak/sk,OAuth2.0

Session会话的引入

随着web应用的告诉发展,越来越多的用户信息需要存储,如果仅仅依靠Cookie字段存储,会大大增加每次请问的负担。
因此引入会话(session)的概念,使用一个会话ID(sessionID)映射到用户的各种信息上,每次请求只需要在cookie携带上sessionID就可以解决cookie增长的问题
接口鉴权,网络,API鉴权,Web,cookie,ak/sk,OAuth2.0

为了更好的负载均衡与容灾,后端服务器一般使用分布式方式部署,一个用户的Session信息在单台服务器上创建后需要同步给其余的服务器。因此Session映射采用Redis等缓存服务器方式才能解决跨地域多机房问题
(为了负载均衡与容灾,Redis集群也需要使用多机房部署)
接口鉴权,网络,API鉴权,Web,cookie,ak/sk,OAuth2.0

局限

  • 依赖cookie,cookie可以被禁用,也可以被劫持篡改
  • 移动端中cookie和session机制不被支持,跨平台不好兼容
  • 缓存服务器的多机房信息同步需要时间,如果服务某个机房出现问题,依然可能造成用户Session短暂失败

二、token授权之JWT

分散压力

既然基于cookie的session鉴权存在上述问题,那么能否改变一下思路,跳出以上的局限性。
Session会话机制的痛点在于,Session的用户解析需要后端服务来维护逻辑,甚至还需要一个缓存服务器来维护,这使得一次请求的链路变长,出现问题的概率也比较大
那干脆让客户端来维护自己的用户信息就好了,这样大量的用户信息就分散到各个用户的设备上,服务器的压力就会减少很多
客户维护鉴权信息的机制类似于http协议也是无状态的,这也使得整个服务拓展性大大提升

用token代替session

  • 用户第一次登录,服务器验证用户,通过后生成一个token
  • 在第一次返回时将token返回给客户端,客户端存储下来,下次请求时携带上该token
  • 之后只要验证token是否有效即可
  • 为了避免篡改,可以在token中使用加密算法生成签名,加入token(私钥保存在服务器上,因此签名无法被破解)
    接口鉴权,网络,API鉴权,Web,cookie,ak/sk,OAuth2.0
JWT(JSON Web Token)token生成标准

JSON Web Token (JWT)是一个开放标准(RFC 7519),它定义了一种紧凑的、自包含的方式,用于作为JSON对象在各方之间安全地传输信息。因为携带了数字签名,因此该信息可以被验证和信任的
JWT由三部分数据组成,三部分由 点(.) 进行分割

  • Header(头部)
  • Payload(负载)
  • Signature(签名)
    Header.Payload.Signature
Header

Header 部分是一个 JSON 对象,描述 JWT 的元数据,例如:

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

alg属性表示签名的算法(algorithm),默认是 HMAC SHA256(写成 HS256);typ属性表示这个令牌(token)的类型(type),JWT 令牌统一写为JWT
最后,将上面的 JSON 对象使用 Base64URL 算法转成字符串

Payload

Payload 部分也是一个 JSON 对象,用来存放实际需要传递的数据。JWT 规定了7个官方字段,可以从中选择使用

iss (issuer):签发人
exp (expiration time):过期时间
sub (subject):主题
aud (audience):受众
nbf (Not Before):生效时间
iat (Issued At):签发时间
jti (JWT ID):编号

当然也可以自定义字段,不过由于这部分数据是明文传送,所以不要在payload字段上存放任何私密信息

Signature

Signature 部分是对前两部分的签名,防止数据篡改。
首先,需要指定一个密钥(secret)。这个密钥只有服务器才知道,不能泄露给用户。然后使用 Header 里面指定的签名算法(默认是 HMAC SHA256),按照下面的公式产生签名。

HMACSHA256(base64UrlEncode(header)+"."+base64UrlEncode(payload),secret)

算出签名以后,把 Header、Payload、Signature 三个部分拼成一个字符串,每个部分之间用"点"(.)分隔,就可以返回给用户
因为使用了签名,因此即使泄露,也无法被篡改

局限
  • 服务器不保存Session信息,在没有特殊逻辑的情况下,无法在使用过程中废止某个 token,也不能更改 token 的权限,一旦 JWT 签发了,在到期之前就会始终有效
  • Token本身就是认证信息,一旦泄露,任何人都可以获得该令牌的所有权限。为了减少盗用,JWT 的有效期应该设置得比较短。对于一些比较重要的权限,使用时应该再次对用户进行认证
  • 为了减少盗用,JWT 不应该使用 HTTP 协议明码传输,要使用 HTTPS 协议传输

三、token授权之OAuth2.0

严格来讲,OAuth2.0不算一种授权方式,而是一个安全的授权认证的框架。为系统中不同角色、用户、服务前端应用(比如API),以及客户端(比如网站或移动App)提供了一套相互认证的框架
所以一般而言,在OAuth2.0中存在三种角色:服务提供方,用户,第三方服务 ;用户授权第三方服务使用自身的某些权限,去访问服务提供方的资源(比如用qq账户登录微博)

OAuth2.0分为两步,获取Authorization以及获取Token

获取Authorization

  • 用户在授权界面,选择需要授权的权限点,登录确定授权
  • 授权后回调第三方服务的回调地址
  • 通过回调地址,发送Authorization(可以看做是验证码,有效期不长)给第三方服务

获取Token并维护Token有效性

  • 通过上面拿到的Authorization调用服务提供方的接口获取token
  • token由access token与refresh token两个token组成,access token有效性比refresh token短
  • 访问服务提供方接口需要使用access token,而当access token快过期的时候就需要用refresh token请求token刷新接口,获取新的token
    接口鉴权,网络,API鉴权,Web,cookie,ak/sk,OAuth2.0
    OAuth 2.0 rfc文档:https://www.rfc-editor.org/rfc/rfc6749

OAuth2.0提供了4种认证方式,上面是最为复杂的一种,授权码模式,其余3种授权方式如下

简化模式

不通过第三方应用程序的服务器,直接在浏览器中向认证服务器申请令牌,跳过了"授权码"这个步骤。所有步骤在浏览器中完成,令牌对访问者是可见的,且客户端不需要认证
接口鉴权,网络,API鉴权,Web,cookie,ak/sk,OAuth2.0

(A)客户端将用户导向认证服务器。
(B)用户决定是否给于客户端授权。
(C)假设用户给予授权,认证服务器将用户导向客户端指定的"重定向URI",并在URI的Hash部分包含了访问令牌。
(D)浏览器向资源服务器发出请求,其中不包括上一步收到的Hash值。
(E)资源服务器返回一个网页,其中包含的代码可以获取Hash值中的令牌。
(F)浏览器执行上一步获得的脚本,提取出令牌。
(G)浏览器将令牌发给客户端。

密码模式

用户向客户端提供自己的用户名和密码。客户端使用这些信息,向"服务商提供商"索要授权。
在这种模式中,用户必须把自己的密码给客户端,但是客户端不得储存密码。这通常用在用户对客户端高度信任的情况下,比如客户端是操作系统的一部分,或者由一个著名公司出品。而认证服务器只有在其他授权模式无法执行的情况下,才能考虑使用这种模式
接口鉴权,网络,API鉴权,Web,cookie,ak/sk,OAuth2.0

(A)用户向客户端提供用户名和密码。
(B)客户端将用户名和密码发给认证服务器,向后者请求令牌。
(C)认证服务器确认无误后,向客户端提供访问令牌。

客户端模式

指客户端以自己的名义,而不是以用户的名义,向"服务提供商"进行认证
接口鉴权,网络,API鉴权,Web,cookie,ak/sk,OAuth2.0

(A)客户端向认证服务器进行身份认证,并要求一个访问令牌。
(B)认证服务器确认无误后,向客户端提供访问令牌。文章来源地址https://www.toymoban.com/news/detail-775875.html

优点

  • 更安全,客户端不接触用户密码
  • 资源服务器可以和授权服务器解耦
  • 适用多种客户端架构场景

缺点

  • 协议框架太宽泛,每个服务又都自己的实现,兼容性和互操作性比较差
  • 客户端需要维护token有效性,维护定时刷新token任务

四、ak/sk认证鉴权

  • 服务提供方需要给每个用户分配一对 Access Key Id(AK) / Secret Access Key(SK)
  • 双方约定同样的加密算法,利用 时间戳,sk,nonce(一个随机值,为了避免请求重放),参数等信息作为计算因子,算出sign签名
  • 用户在调用api时,需要提供自己的身份认证(AK),时间戳、nonce以及加密好的sign签名
  • 服务提供方验证签名是否过期,验证nonce是否唯一,并利用同样的算法算出sign,与传入sign进行比对,如果一致则通过认证
    接口鉴权,网络,API鉴权,Web,cookie,ak/sk,OAuth2.0

优点

  • 安全性高,在秘钥与算法不泄露情况下,签名无法破解
  • 有过期时间,可以避免签名长期有效的情况
  • 有防止重放机制,即使签名被捕获,也无法再次利用相同的签名进行请求

缺点

  • 对于服务调用方与被调用方都需要一定的编码要求
  • 每次请求都需要重新计算签名,不那么轻量
  • 服务提供方需要维护ak/sk关系,并且需要维护nonce是否唯一逻辑

到了这里,关于Web API接口鉴权方式的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • JWT VS OAuth2, 如何设计一个安全的API接口?

    Client Profile客户端描述 OAuth2框架也指定了集中客户端描述,用来表示应用程序的类型: Web应用 用户代理 原声应用 Authorization Grants认证授权 认证授权代表资源拥有者授权给客户端应用程序的一组权限,可以是下边几种形式: 授权码 隐式授权 资源拥有者密码证书 客户端证书

    2024年04月11日
    浏览(42)
  • 【全栈接口测试进阶系列教程】postman接口测试实战cookie,token,session鉴权,Base64,MD5,RSA加密,Sign签名,持续集成postman+Newman+jenkins

    目录 【一:postman简介和安装以及postman的登录和注册】 一、postman下载 二、安装、注册/登陆 三、简单使用 1.postman模拟发送get请求: 2.postman模拟发送post请求:  3.post数据类型说明: 【二:postman发送get请求,post请求实战以及页签详解】 发送GET请求 响应页面 发送POST请求 【三

    2024年02月10日
    浏览(54)
  • 对接第三方接口鉴权(Spring Boot+Aop+注解实现Api接口签名验证)

    一个web系统,从接口的使用范围也可以分为对内和对外两种,对内的接口主要限于一些我们内部系统的调用,多是通过内网进行调用,往往不用考虑太复杂的鉴权操作。但是,对于对外的接口,我们就不得不重视这个问题,外部接口没有做鉴权的操作就直接发布到互联网,而

    2024年04月29日
    浏览(83)
  • Postman界面功能详情、常见鉴权处理方式、接口关联

    目录 1.接口及其类型 2.接口测试的流程 3.Postman执行接口测试 3.1 界面功能 3.2 请求 1. 请求方式 2. 接口地址 3.查询字符串 4. 鉴权方式 5. 请求头 6.请求正文 7. 请求预处理 8. 测试用例 9. 设置 10. cookie 3.2 响应 3.3 Postman环境变量和全局变量 3.4 使用集合来管理请求 3.5 Postman断言

    2023年04月09日
    浏览(31)
  • 第六十六天 API安全-接口安全&阿里云KEY%postman&DVWS&XEE&鉴权&泄露

    1.HTTP类接口-测评 2.RPC类接口-测评 3.Web Service类-测评 参考链接:https://www.jianshu.com/p/e48db27d7c70 内容点: SOAP(Simple Object Access Protocol)简单对象访问协议是交换数据的一种协议规范, 是一种轻量的、简单的、基于XML(标准通用标记语言下的一个子集)的协议,它被设计 成在WEB上

    2024年02月22日
    浏览(36)
  • 爆炸性!接口鉴权方式及实战案例,这篇文章让你的接口安全像坦克防护!

    接口鉴权是指在访问API接口时对用户进行身份验证和权限检查,以确保API接口的安全性和可靠性。常见的接口鉴权方式包括API Key、Basic Authentication、OAuth、Token 等。本文将详细解析这些常见的接口鉴权方式,并使用Python代码进行演示。 一、API Key API Key 是一种基于密钥的验证方

    2024年02月16日
    浏览(46)
  • rust actix-web定义中间件(middleware)记录接口耗时(接口耗时中间件和鉴权中间件)

    actix-web的官网关于中间件的介绍如下 https://actix.rs/docs/middleware/ 这里使用的是最新版的actix-web,旧版本的可能接口不太一样 我们添加的中间件能干什么?我们用一段代码来观察一下 下面是官方提供的中间件的定义方式之一,我们可以看到闭包里面有两个参数 req 和 srv 其中

    2024年02月11日
    浏览(43)
  • Spring Gateway + Oauth2 + Jwt网关统一鉴权

    之前文章里说过,分布式系统的鉴权有两种方式,一是在网关进行统一的鉴权操作,二是在各个微服务里单独鉴权。 第二种方式比较常见,代码网上也是很多。今天主要是说第一种方式。 重要前提:需要收集各个接口的uri路径和所需权限列表的对应关系,并存入缓存。 服务

    2024年02月03日
    浏览(45)
  • 微服务鉴权中心之网关配置SpringSecurity+oauth2

    微服务鉴权中心流程如下: 1. 网关配置oauth2之 TokenStore存储方式,此处用 RedisTokenStore 2.网关配置security 3.网关拦截token

    2024年02月14日
    浏览(38)
  • Spring Cloud Gateway + Oauth2 实现统一认证和鉴权!

    micro-oauth2-gateway:网关服务,负责请求转发和鉴权功能,整合Spring Security+Oauth2; micro-oauth2-auth:Oauth2认证服务,负责对登录用户进行认证,整合Spring Security+Oauth2; micro-oauth2-api:受保护的API服务,用户鉴权通过后可以访问该服务,不整合Spring Security+Oauth2。 我们首先来搭建认

    2024年01月16日
    浏览(59)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包