一般有以下几种认证方式:
Token认证
AK/SK认证
RSA非对称加密方式
Token认证
使用Token认证方式完成认证鉴权时,用户首先需要获取token,在调用接口时增加“X-XXX-Token”到业务接口请求消息头中。
流程
原理:任何请求,都附带token;服务端根据token判断请求是否合法。
缺点:若是报文在中途被劫持,那么token就泄露了,这时(token有效期内)黑客就能够构造任意的请求了。
2 AK/SK认证
2.1 AK/SK 原理
云主机需要通过使用Access Key Id / Secret Access Key加密的方法来验证某个请求的发送者身份。
Access Key Id(AK)用于标示用户,Secret Access Key(SK)是用户用于加密认证字符串和云厂商用来验证认证字符串的密钥,其中SK必须保密。 AK/SK原理使用对称加解密。
2.2 AK/SK使用机制
云主机接收到用户的请求后,系统将使用AK对应的相同的SK和同样的认证机制生成认证字符串,并与用户请求中包含的认证字符串进行比对。如果认证字符串相同,系统认为用户拥有指定的操作权限,并执行相关操作;如果认证字符串不同,系统将忽略该操作并返回错误码。
2.3 流程
判断用户请求中是否包含Authorization认证字符串。如果包含认证字符串,则执行下一步操作。
基于HTTP请求信息,使用相同的算法,生成Signature字符串。
使用服务器生成的Signature字符串与用户提供的字符串进行比对,如果内容不一致,则认为认证失败,拒绝该请求;如果内容一致,则表示认证成功,系统将按照用户的请求内容进行操作。
原理:
在实际的网站设计中我们经常会遇到用户数据的验证和加密的问题,如果实现单点,如果保证数据准确,如何放着重放,如何防止CSRF等等。
其中,在所有的服务设计中,都不可避免的涉及到Token的设计。
目前,基于Token的生成方,我们把Token生成分为两种类型。
1、基于用户/网站,可见的加密请求方式
2、基于服务器间通讯的不可见加密请求方式(API Token)
其中,基于非服务器端的请求,我们要根据实际的应用场景进行一定的自定义加工。
在本次讨论中我们把非服务的请求分为了两部分。
两种请求中:
1、非登录态请求要求用户访问页面时会随机生成唯一且有时效性的token,该token在每次请求时都是不同。改方法用于当不需要登录界面的请求多且无法使用静态页面的时候使用,Token会在一定的时间内失效,以此来防止被机器爬取不需登录的界面
2、登录状态中,token会保存一定的时间,页面中的token会作为用户身份识别,同时登录态的Token需要利用session和页面信息来防止被利用。
虽说两者作用有一定的区别,但是实现的原理是相同的。
登录态的Token一般在用户登录之后由服务器产生,并保存在浏览器中,过期时间较长,用于保存用户的登录状态。
同时,我们也可以在该Token中加入一定的校验元素,例如浏览器信息,ip,获取是Cookies
如果对时效性较强的页面登录访问,我们可以加入session的校验,设置session的有效时间,能够实现自动退出的校验功能。
TimeStamp用来校验Token的生成时间。
同时,你用redis的Hset可以实现多点登录和单点登录的功能。
服务端验证Token:
在常规的API Token体系中,我们常使用短时过期Token(Oauth Token除外)。
通常 APIToken 是使用非对称加密来实现token的生成,但是世界生产中,Token 的秘钥会简化成app_id,app_key等简单的加盐参数,不过只要秘钥保存合理,Token基本无法被破解。
该Token方式要求每次请求都需要生成新的token来确保请求的时效性。
另外:为了加强API接口请求的完整性,我们也会对请求内容进行字段排序后摘要验证。(详情参考: https://open.taobao.com/docV2.htm?docId=101617&docType=1 )
欢迎分享,转载请注明来源:夏雨云
评论列表(0条)