关于四种鉴权方式

概念

鉴权:验证用户是否拥有访问系统的权利。

传统的鉴权是通过密码来验证的,这种方式的前提是,每个获得密码的用户都已经被授权。在建立用户时,就为此用户分配一个密码,用户的密码可以由管理员指定,也可以由用户自行申请。这种方式的弱点十分明显:一旦密码被偷或用户遗失密码,情况就会十分麻烦,需要管理员对用户密码进行重新修改,而修改密码之前还要人工验证用户的合法身份。

鉴权方式

HTTP Basic Authentication

HTTP协议实现的基本认证方式,此方式在客户端会弹出一个登录窗口,由用户输入用户名和密码进行登录,安全性不高。

Session-Cookie 认证

利用服务端的 Session(会话)和浏览器(客户端)的 Cookie 来实现的前后端通信认证模式。

当客户端第一次向服务器发送请求,服务器第一次接收到请求时,为此请求开辟一块内存空间(一个Session对象),服务器会为这个Session对象生成一个唯一的标识sessionID,并在HTTP响应头的 Set-Cookie:JSESSIONID=XXXXXXX 中设置这个sessionID(Session的实现依赖Cookie)。

客户端收到服务端的响应后会解析响应头,根据Set-Cookie将sessionID保存在本地Cookie中,当下次向服务器发送请求时,请求头会自动附上该域名下的 Cookie 信息,而服务端接收客户端请求时会去解析请求头 Cookie 中的sessionID,根据sessionID找到Session对象,从而获取用户信息。

这个 sessionID 一经创建,就在后面的每次 http 请求中,都带在请求头当中。服务器就是靠这种标识,来区别客户端是哪一个的。

但是 sessionID 是基于Cookie存储的方式保存,如果Cookie被截获,用户就容易受到跨站请求伪造的攻击,这是不安全的。

Token 验证

Token实际就是在计算机身份验证中的令牌(临时)的意思。当前端向后端发起数据请求的时候,后端需要对前端进行身份验证,但是我们又不想每次都输入用户名和密码,这是就需要一个标识来证明自己的身份,这个标识就是token。

这种验证是在 App 兴起以后发展起来的,因为在 App 里没有浏览器环境,没有Cookie,那么客户端在进行了权限验证以后,就把这个登录凭证,也就是 Token 直接存在了客户端,并且在每次请求服务器的时候都把它带上。最常用的 Token 验证方式,就是 JWT (Json Web Token) ,JWT是通过对带有相关用户信息的json进行加密,加密的方式比较灵活。

基于Token的身份验证流程:

客户端使用用户名和密码请求登录
服务端收到请求,验证登录是否成功
验证成功后,服务端会返回一个Token给客户端,反之,返回身份验证失败的信息
客户端收到Token后把Token用一种方式存储起来 ( cookie / localstorage / sessionstorage /... )
客户端每次发起请求时都会将Token发给服务端
服务端收到请求后,验证Token合法性,合法就返回客户端所需数据,反之,返回验证失败的信息

OAuth 验证

OAuth(开放授权)是一种开放标准,用于允许用户在不暴露其凭据(如用户名和密码)的情况下,让第三方应用程序访问其资源(如用户的照片、视频、联系人列表等)。OAuth 主要用于授权,而不是身份验证。如网站第三方登录,可以使用 QQ 或者微信登录,小程序微信一键登录。

Session、Cookie、Token

HTTP 协议是一种无状态协议,即每次服务端接收到客户端的请求时,都是一个全新的请求,服务器并不知道客户端的历史请求记录,Session 和 Cookie 的主要目的就是为了弥补 HTTP 的无状态特性。

Cookie和Session是两种常见的用于跟踪使用者状态和实现使用者认证的机制。Cookies是一种存储在客户端的数据机制,而Session则是一种在服务器端存储使用者信息的机制。

客户端请求服务端,服务端会为这次请求开辟一块内存空间,这个对象便是 Session 对象,服务器可以利用 Session 存储客户端在同一个会话期间的一些操作记录(用户在浏览网站时,记录用户从进入网站到关闭浏览器所经历的一系列状态和行为)。

Session工作原理:

Cookie工作原理:

Session与Token:作为身份认证,Token安全行比Session好; Session 认证只是简单的把User 信息存储到Session里,因为SID 的不可预测性,暂且认为是安全的,这是一种认证手段。 而Token ,如果指的是OAuth Token 或类似的机制的话,提供的是认证和授权,认证是针对用户,授权是针对App ,其目的是让某App有权利访问某用户的信息。

Token与Cookie:Cookie是不允许垮域访问的,但是Token是支持的, 前提是传输的用户认证信息通过HTTP头传输;Token就是令牌,比如你授权(登录)一个程序时,他就是个依据,判断你是否已经授权该软件;Cookie就是写在客户端的一个txt文件,里面包括你登录信息之类的,这样你下次在登录某个网站,就会自动调用Cookie自动登录用户名。

Cookie与Session区别:Cookie数据存放在客户端上,Session数据放在服务器上;Cookie不是很安全,且保存数据有限;Session一定时间内保存在服务器上,当访问增多,占用服务器性能。

参考:

终于有人把前端鉴权讲明白了

鉴权的基本概念及session和cookie的入门认识

Session、Cookie、Token 【浅谈三者之间的那点事】

Cookie的工作原理和应用详解

session 详解:掌握客户端会话管理

Cookie vs Session:全面对比分析,探讨优点和适用场景

30s 看懂最基础的认证方式: Session-Cookie 认证

Token及Token验证流程

  • 12
    点赞
  • 11
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
毕业设计,基于SpringBoot+Vue+MySQL开发的海滨体育馆管理系统,源码+数据库+毕业论文+视频演示 本基于Spring Boot的海滨体育馆管理系统设计目标是实现海滨体育馆的信息化管理,提高管理效率,使得海滨体育馆管理工作规范化、高效化。 本文重点阐述了海滨体育馆管理系统的开发过程,以实际运用为开发背景,基于Spring Boot框架,运用了Java技术和MySQL作为系统数据库进行开发,充分保证系统的安全性和稳定性。本系统界面良好,操作简单方便,通过系统概述、系统分析、系统设计、数据库设计、系统测试这几个部分,详细的说明了系统的开发过程,最后并对整个开发过程进行了总结,实现了海滨体育馆相关信息管理的重要功能。 本系统的使用使管理人员从繁重的工作中解脱出来,实现无纸化办公,能够有效的提高海滨体育馆管理效率。 关键词:海滨体育馆管理,Java技术,MySQL数据库,Spring Boot框架 本基于Spring Boot的海滨体育馆管理系统主要实现了管理员功能模块和学生功能模块两大部分,这两大功能模块分别实现的功能如下: (1)管理员功能模块 管理员登录后可对系统进行全面管理操作,包括个人中心、学生管理、器材管理、器材借出管理、器材归还管理、器材分类管理、校队签到管理、进入登记管理、离开登记管理、活动预约管理、灯光保修管理、体育论坛以及系统管理。 (2)学生功能模块 学生在系统前台可查看系统信息,包括首页、器材、体育论坛以及体育资讯等,没有账号的学生可进行注册操作,注册登录后主要功能模块包括个人中心、器材管理、器材借出管理、器材归还管理、校队签到管理、进入登记管理、离开登记管理、活动预约管理。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值