登录的两种方式

hahala2333

于 2023-05-15 10:11:43 发布

阅读量357

点赞数

文章标签： javascript 前端

本文链接：https://blog.csdn.net/hadry123/article/details/130672533

版权

起源：「购物车」功能需求

1.服务器需要客户端保存的内容，放在set-cookie headers里返回，客户端会自动保存
2.客户端保存的cookies，会在之后的所有请求里都携带进cookie header里发送给服务器
3.客户端保存cookie是按照服务器域名来分类的，例如shop.com发回的cookie保存下来以后，在之后向games.com的请求中并不会携带。
4.客户端保存的cookie在超时后会被删除、没有设置超时时间的cookie（称作session cookie）在浏览器关闭后就会自动删除；另外，服务器也可以主动删除还未过期的客户端cookies

跨站脚本攻击，即使用javascript拿到浏览器的cookie之后，发送到自己的网站，以这种方式来盗取用户cookie。

应对方式：server在发送cookie时，敏感的cookie加上HttpOnly。

跨站请求伪造。即在用户不知情的情况下访问已经保存了cookie的网站，以此来越权操作用户账户（例如盗取用户资金）。应对方式主要是从服务器安全角度考虑。

应对方式：Referer校验

1.增加请求体积，浪费性能，因为每次都会携带cookie
2. 增加服务端资源消耗，因为每个客户端连接进来都需要生成session，会占用服务端资源
3. 容易遭受CSRF攻击，即跨站请求伪造

数据存储
cookie的数据始终在http的同源请求中存储，数据可以在客户端与服务端进行回传，webStorage的数据只能进行本地存储，不能向服务器进行传递
生命周期
sessionStorage是会话级别的缓存，当次会话结束后缓存数据被清除
localStorage是永久缓存，直到被手动清除
cookie可以设置生命周期，到该时间失效
存储的数据量
每次http的请求都会携带cookie，所以cookie的大小要求不能超过4k，webStorage数据因为只存储在本地，对数据存储量可以达到4-5M
作用域
sessionStorage作用在同一会话之间，不在不同浏览器窗口（标签页）共享、即使同源，cookie、localstorage在所有同源窗口之间共享
应用场景
localStoragese：适合长期保存在本地的数据。sessionStorage：敏感账号一次性登录；cookie+session 是实现认证的一种非常好的方式

格式：Authorization：Basicusername:password(Base64ed)

http有风险，https无事

格式：Authorization：Bearer

通过OAuth2授权流程

第三方网站向授权方网站申请第三方授权合作，拿到client id和client secret
用户在使用第三方网站时，点击「通过XX（如GitHub）授权」按钮，第三方网站将跳转到授权方网站，并传入client id作为自己的身份标识
授权方网站根据client ID，将第三方网站的信息和第三方需要的用户权限展示给用户，并询问是否同意授权
用户点击「同意授权」按钮后，授权方网站将页面跳转回第三方网站，并传入Authorization code作为用户认证凭证。
第三方网站将Authorization code发回自己的服务器
服务器将Authorization code和自己的client secret（严格保密）一并发送给授权方的服务器（https），授权方服务器通过验证后，返回access token。OAuth流程结束
上面的过程结束后，第三方网站服务器（或者客户端也会，客户端使用不安全，会泄漏token，这样做Authorization code的环节失去了作用）就可以使用access token作为用户授权令牌，向授权网站发送请求来获取用户信息或操作用户账户。但这已经在OAuth流程之外。

为什么OAuth要引入Authorization code，并需要申请授权的第三方将Authorization code发送回自己的服务器，再从服务器来获取access token，而不是直接返回access token？

为了安全。OAuth不强制授权流程必需使用https，因此需要保证当通信路径中存在窃听者时，依然具有足够高的安全性。

在自家App中使用Bearer token

有的APP在API设计中，将登录和授权设计成类似OAuth2的过程，但简化掉Authorization code的概念。
即：登录接口请求成功时，返回access token来当做bearer token进行用户操作了

第三方App通过微信登录的流程，也是一个OAuth2流程

第三方App向腾讯申请第三方授权合作，拿到client id 和client secret
用户在使用第三方App时点击「通过微信登录」，第三方App将使用微信SDK跳转到微信，并传入自己的client ID作为字节的身份识别
微信通过和服务器交互，拿到第三方App信息，并显示在界面中，然后询问用户是否同意授权该App使用微信来登录
用户点击「使用微信登录后」，微信和服务器交互将授权信息提交，然后跳回第三方APP，并传入Authorization code作为用户认可凭证。
第三方APP调用自己服务器的「微信登录」api，并传入Authorization code，然后等待服务器响应。
服务器在收到登录请求后，拿收到的Authorization code去向微信的第三方授权接口发送请求，将Authorization code和自己的client secret一起作为参数发送，微信验证通过后，返回access token
服务器在收到access token后，立即拿着access token去向微信用户信息接口发送请求，微信验证信息通过后返回用户信息
服务器在收到用户信息后，在自己的数据库中为用户创建一个账户，并使用从微信服务器拿来的用户信息填入自己的数据库，以及将用户的ID和用户的微信ID做关联
用户创建完成后，服务器向客户端的请求发送响应，传送回刚创建好的用户信息
客户端收到服务器响应，用户登录成功

###

关注