权限的相关内容

目录

• 权限的四个概念
• • 认证
  • 授权
  • 鉴权
  • 权限验证
• 挑战/应答（Challenge/Response）
• 授权⽅式/身份凭证
• • cookie
  • session
  • 储存位置
  • • php
    • flask
    • java
    • gin/其他可选的地⽅
• jwt认证
• AK/SK认证

权限的四个概念

认证

根据声明者持有的特定信息，来确认声明者的身份关键点是特定信息，这个信息，⼀般也称为认证因素。⽐如最常⻅的⽤户名密码，说⽩了，就是我要⽤这些信息来证明“我是我”。
更具体的，如何证明“我是我”？其实就是⼀个信息⽐较的过程，⼀定要预先有⼀个数据库来储存原信息。

授权

服务器给予的临时凭证，持有该凭证的⽤户即认为已经经过了认证，⽆需再次进⾏认证。（⽤户在后续的访问中，只需要出示凭证即可，⽆需⼀次⼀次的进⾏认证）并且，在授权的过程中，要明确的是权限也是划分等级的。⼀个管理员账户与⼀个普通⽤户账户⾃然不能⽐较。

鉴权

鉴定⽤户是否持有授权
鉴定⽤户的授权是否有效
鉴定⽤户的授权的等级

权限验证

其实权限验证跟鉴权的界限⾮常模糊，或者可以说权限验证/权限控制（ACL）是鉴权的⼦集也不为过。为什么要单独拿出来，就是为了引出具体的“动作”权限验证这个概念。

挑战/应答（Challenge/Response）

# 输出挑战信息
print("Hello! Challenge here!")
 
# 生成挑战码，一般是个随机字符串之类的
code = ChallengeCodeGenerator()
 
# 根据挑战码生成应该得到的应答
resp = responseGenerator(code)
 
# 输出挑战码
print("Here is the ChallengeCode:" + code)
 
# 获取用户应答
user_input = read_input()
 
# 检测用户应答是否正确
if user_input == resp:
    print("You are in")
else:
    print("Out!")

所以说，这种挑战、应答机制是否安全，强依赖于respGenerater中⽣成逻辑。⼀旦其⽣成逻辑开源出来，并且是⼀个环境⽆关的检测逻辑，那么很有可能就被击溃，因为攻击者并不需要考虑任何环境因素。
有⼀个强依赖于环境的变量在其中，⽐如：某设备出⼚的时候，就是⼀机⼀码的，该唯⼀的身份码已经直接硬编码写在机器的/etc/dada⽬录，每个机器都不⼀样。只有⼚商在⾃家的数据库有存，这种情况下，我们就没办法直接预知了。

授权⽅式/身份凭证

cookie

<?php
if ($_COOKIE["user_id"] == 0) {
    echo "你是管理员";
} else {
    echo "你是游客";
}
?>

session

认证成功后后端会⽣成session_id，并且将该session_id存在某个地⽅。
然后做以下操作：

1. 在认证结束的返回（response）中，进⾏set-cookie将session_id告知客户端浏览器
2. 客户端在后续的访问中携带session_Id进⾏访问（持有身份凭证）
3. 从某个地⽅检查该session_id的有效性（鉴权）
4. 根据鉴权结果，确定是否有权限进⾏某动作。

储存位置

php

默认存储在服务端/tmp⽬录下(⽂件)

flask

默认存储在⽤户的cookie中（密钥加密）

java

默认存储在内存中

gin/其他可选的地⽅

redis/mysql/memcached/mongodb

jwt认证

JWT(JSON Web Token)是⼀个开放标准(RFC 7519)，它定义了⼀种紧凑且⾃包含的
⽅式，以JSON对象的形式在各⽅之间安全地传输信息。
JWT是⼀个数字签名，⽣成的信息是可以验证并被信任的。
使⽤密钥(使⽤HMAC算法)或使⽤RSA或ECDSA的公钥/私钥对JWT进⾏签名。
JWT是⽬前最流⾏的跨域认证解决⽅案

AK/SK认证

客户端在调用的服务端接口时候，会带上ak以及signature（使用sk对内容进行加密后得出的签名）进行请求，在服务端接收到这个请求的时候，首先会根据ak去数据库里面去找到对应的sk，然后使用sk对请求内容进行加密得到一个签名，然后对比客户端传过来的签名和服务端计算的出来的签名是否一致，如果一致则代表身份认证通过，反之则不通过。