需求:免密登录
遇到的问题:这个需求谁来做,当然我现在碰到的是前端来做,但是身为程序员要时时刻刻学习,就在想这个需求会不会那次降临到后端,那时候我该怎么做。想要一个思路。
曾想过放权限,但思路不通 ,因为只能有了token才能访问接口 总不能放开每个接口 ,前前后后都绕不开token,除非给他了个永久的token,彻底无奈了 ,这个需求打败了我 ,我暂时没思路了,求教
需求:免密登录
遇到的问题:这个需求谁来做,当然我现在碰到的是前端来做,但是身为程序员要时时刻刻学习,就在想这个需求会不会那次降临到后端,那时候我该怎么做。想要一个思路。
曾想过放权限,但思路不通 ,因为只能有了token才能访问接口 总不能放开每个接口 ,前前后后都绕不开token,除非给他了个永久的token,彻底无奈了 ,这个需求打败了我 ,我暂时没思路了,求教
免密登录在后端实现需要考虑多个方面,下面是一些基本步骤和思路:
* 确保密钥的传输安全,通常使用 HTTPS 进行通信。
* 避免将敏感信息存储在客户端或传输过程中,只存储和传输必要的登录信息。
* 定期清理和更新密钥,以减少被破解的风险。需要注意的是,免密登录虽然方便,但也可能带来安全风险。因此,这种功能应当谨慎使用,并确保所有相关的安全措施都得到妥善实施。
首先生成token是必须的,无论是前端生成还是后端生成,无论是token参数还是其他参数,或者就是短链接,目的都是相同的:识别访问,取回关联信息。
安全考虑,token一般不含有登录信息,后端将token与登录信息关联保存,可保存在缓存或数据库中。
安全和业务需要,token可以是一次性的或者短期有效,后端可以关联IP,浏览器类型增加安全性。
token传输安全,可以考虑https,header,甚至再加密一次。
这应该属于客户端登录的类型。常用的登录方式basic, digest 等方式。就是不需要输入密码,直接以客户端的角色访问。我感觉就是角色转换的问题,一般的情况来说,我们用户是终端用户。而在这种视野下,client 成为了终端用户。oauth2 中的client 访问就是使用这种方式。
还是需要前后端配合,后端给前端双token的机制,一个是短期token(有效期几个小时),另一个是长期token(比如七天有效期),短期token失效,则用长期token去刷新短期token,长期token也失效了也就是至少七天没有账号没有访问过系统了,要求前端引导用户重新登录。
如果要求不高,只要长期token也行。
4 回答961 阅读
4 回答873 阅读
583 阅读
485 阅读
什么叫免密登陆, 然后什么场景下使用?
前端做的话: 应该是这样的,正常的系统获取流程是 用户输入账号密码, 通过登陆接口获取token, 而客户端可以这样实现, 直接不需要用户输入账号密码,直接悄悄把账号密码固定传给登陆接口就能获取token了,
服务端可以这么实现: