权限的相关内容
目录
- 权限的四个概念
- 认证
- 授权
- 鉴权
- 权限验证
- 挑战/应答(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存在某个地⽅。
然后做以下操作:
- 在认证结束的返回(response)中,进⾏set-cookie将session_id告知客户端浏览器
- 客户端在后续的访问中携带session_Id进⾏访问(持有身份凭证)
- 从某个地⽅检查该session_id的有效性(鉴权)
- 根据鉴权结果,确定是否有权限进⾏某动作。
储存位置
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对请求内容进行加密得到一个签名,然后对比客户端传过来的签名和服务端计算的出来的签名是否一致,如果一致则代表身份认证通过,反之则不通过。