<?phprequire'vendor/autoload.php';use\Firebase\JWT\JWT;define('KEY','1gHuiop975cdashyex9Ud23ldsvm2Xq&#...
<?php
require 'vendor/autoload.php';
use \Firebase\JWT\JWT;
define('KEY', '1gHuiop975cdashyex9Ud23ldsvm2Xq'); //密钥
function getToken($userid, $username){
$nowtime = time();
$data = [
'iss' => 'server', //签发者
'aud' => 'client', //jwt所面向的用户
'iat' => $nowtime, //签发时间
'nbf' => $nowtime + 10, //在什么时间之后该jwt才可用
'exp' => $nowtime + 600, //过期时间-10min
'data' => ['userid' => $userid,'username' => $username]
];
return JWT::encode($data, KEY);
}
function checkToken($token){
if (empty($token)) {
$res['msg'] = '无效的Token.';
echo json_encode($res);
exit;
}
try {
JWT::$leeway = 60;
$decoded = JWT::decode($token, KEY, ['HS256']);
$arr = (array)$decoded;
if ($arr['exp'] < time()) {
$res['msg'] = '认证超时,请重新登录';
} else {
$res['result'] = 'success';
$res['info'] = $arr;
}
} catch (\Firebase\JWT\SignatureInvalidException $e) { //签名不正确
echo $e->getMessage();
} catch (\Firebase\JWT\BeforeValidException $e) { // 签名在某个时间点之后才能用
echo $e->getMessage();
} catch (\Firebase\JWT\ExpiredException $e) { // token过期
echo $e->getMessage();
} catch (Exception $e) { //其他错误
echo $e->getMessage();
}
return json_encode($res);
}
function authorizations(){
$time = time(); //当前时间
$userid=1;
$username="admin";
$data = [
'iss' => 'server', //签发者
'aud' => 'client', //jwt所面向的用户
'iat' => $time, //签发时间
'data' => ['userid' => $userid, 'username' => $username]
];
$access_token = $data;
$access_token['scopes'] = 'role_access'; //token标识，请求接口的token
$access_token['exp'] = $time + 7200; //access_token过期时间,这里设置2个小时
$refresh_token = $data;
$refresh_token['scopes'] = 'role_refresh'; //token标识，刷新access_token
$refresh_token['exp'] = $time + (86400 * 30); //access_token过期时间,这里设置30天
$jsonList = [
'access_token' => JWT::encode($access_token, KEY),
'refresh_token' => JWT::encode($refresh_token, KEY),
'token_type' => 'bearer' //token_type：表示令牌类型，该值大小写不敏感，这里用bearer
];
Header("HTTP/1.1 201 Created");
return json_encode($jsonList); //返回给客户端token信息
}
$tokens=json_decode(authorizations());
var_dump($tokens);
$access_token=json_decode(checkToken($tokens->access_token));
$refresh_token = json_decode(checkToken($tokens->refresh_token));
var_dump($access_token->info);
echo "accesstoken exped" . date("Y-n-d H:i:s", $access_token->info->exp);
echo "<br>refresh_token exped".date("Y-n-d H:i:s", $refresh_token->info->exp);
var_dump($refresh_token->info);移动APP的特点
移动APP和网页登陆不同的一点就是,App不需要用户每次使用都登陆,增加了易用性, 本文介绍一下App保持登陆的是实现机制
目前常见的机制:
一 使用传统的会话机制session
把网页的机制照搬过来,利用传统网页的记住登陆机制.
用户输入正确的用户名和密码后,创建登陆会话,同时生成一个记住登陆token保持在服务器端,同时发个客户端.
客户端每次启动时,通过记录登陆token新建会话,后续使用便采取session机制.
服务器端的可用Memcache 或 Redis 存储会话.
回味一下这个机制,其中的记住登陆token,也可定个长的有效期,比如30天,
记住登陆token类似Oauth 2.0 的 Refresh token, Session机制里的Session Id 类似Access token.
只不过,Session机制里的Session Id 持续使用时,会自动延期.
这个机制的好处是充分利用现有知识,简单易用,没有太多新名词概念
不足之处是不便于分布式认证,还有Session机制对性能有一小点影响, 同时不符合Restful API无状态的设计精神.
二 使用一个有效期很长的Token 机制
用户正确登陆后,生成一个有效期很长的Token(比如半年),保存在服务器端,同时发给客户端, 客户端的每次请求就以这个Token验证身份.
采用https 传输加密, Token中途不会被获取, 而保存在本地的Token其他程序也访问不了.
对应普通应用而言,这个方案也是可以的.
三 使用一个长期的Refresh Token 和 短期的Access Token.
对于方案二, 如果手机硬件本身被黑客获取过, 长期Token可能被盗,有潜在的风险.
考虑到这一点, Oauth 2.0 标准推荐采用Refresh Token和Access Token.
Refresh Token 有效期很长, Access Token 有效期很短.
用户登陆后,同时获得Refresh Token 和 Access Token,平时就用 Access Token, Access Token 过期后就用Refresh Token 获取新的Access Token.
这个方案使用很广泛,包括微信公众平台开发 也使用这个机制
但细细一想, 这个机制并不比方案二(使用一个长期的token)安全,
黑客如果能够获取Access Token,获取Refresh Token也不难,采用两个token 仅仅是给黑客增加点小麻烦.
一旦黑客获取了获取Refresh Token, 就可反复的刷新的Access Token
Token以旧换新的机制
这个机制只使用一个短期的Token,比如1天.
用户登陆后, 这个Token发给客户端, 用户每次请求就使用这个Token认证身份, Token过期后凭此token换取新的Token,一个过期的Token只能换取一个新的Token,这是关键. 如果Token被盗, 黑客要持续使用也需持续的换取新的Token, 服务器一旦发现,一个旧Token多次试图换取新Token,表示有异常. 这时强制用户再次登陆.
Token旧换新,不一定等过期了才换,应用启动时就可旧换新,这个视具体情况而定.
这个Token的有效期,针对不同的应用可以调整.
以设计招商银行的app为例:
1, 采用https 加密,确保传输安全.
2,Token的有效期设为15分钟,Token每15分钟,以旧换新换取新的Token. 正常情况下,这个以旧换新对用户不可见,一但两人试图以旧换新,两人都阻止,需要再次登陆.
3,对于修改密码和转账支付这样的关键操作,要求用户输入密码.
这样就万无一失了.
重复一下,设计安全机制时,一定要使用https, 没有https, 多数安全设计都是无用功
附: Token 简介
Token 中文的翻译就是令牌, 识别身份的依据.
通常token有两种:
一 不含内容的token
这种token这是一个唯一的hash值, 要知道这个token是谁,要到一个中心服务器查询.
在中心服务器,用户数据可能储存于文件或是数据库或是Redis等.
在session 机制的Cookie里 有一个session id, 本质上也是一个这类token.
二 包含内容的token
这种token, 就像一个身份证,包含公开的用户信息, 通过签名机制确保token无法伪造.
最常见的这类token 就是: Json web token (JWT)
这种token好处是不用到中心服务器查询,对于分布式系统很有用, 比如用户登陆后,要看视频,要下载文件.
而视频,文件资源都需验证用户身份,视频,文件资源在不同的服务器,甚至由不同的公司提供,这时可分布式验证的JWT就很有用.
这种可分布式验证的Token通常发行了就不能注销,只能等其自行过期失效.
这时为了保证安全性,使用短期JWT,再加上述的token以旧换新,就很有效.
本文所说的Token旧换新机制,对上述两种token均适用.
Token 就是一个字符串信息,就算复制一万份,彼此也毫无差别,
有了以旧换新的机制,Token就有点像实物了, 已经换过了自然不能再换,不管有多少份,只能有一个换取新的Token
当两个人先后拿着同一个token 来换新,我们不能判断到底哪个合法,哪个非法,好吧,两人都再次登陆确认身份吧.
更新
对于普通的应用,有效期设为24小时,每次启动应用时换一下token就可以,不用太复杂
对于网银这样的应用, 启动时换一下, 再加上用个定时器(timer),每15分钟换一下token就可以.
作者：黄洪清
链接：https://www.jianshu.com/p/b4cf771e570e
來源：简书
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。
*/
全文详见：http://xpxw.com/?id=71