有哪些常见的前后端鉴权方式概述？
- 内容介绍
- 文章标签
- 相关推荐
本文共计1265个文字，预计阅读时间需要6分钟。
在最新重构公司产品前端代码时，我们移除了原有的session-cookie授权方式，转而采用token授权。以下是一些常见的授权方式整理：
1. HTTP Basic认证：基于用户名和密码的简单文本传输，安全性较低，不推荐用于敏感信息传输。
2.OAuth 2.0：一种授权框架，允许第三方应用访问服务器资源。它支持多种授权类型，如密码、授权码、客户端凭证等。
3.JWT (JSON Web Tokens)：一种用于在网络应用之间安全传输信息的简洁、自包含的格式。JWT包含一个签名，可用于验证其完整性和真实性。
4.API Key：为特定应用或用户分配一个密钥，用于访问API时的身份验证。
以上几种方式各有优劣，需根据实际需求和安全要求选择合适的授权方式。
最近在重构公司以前产品的前端代码，摈弃了以前的session-cookie鉴权方式，采用token鉴权，忙里偷闲觉得有必要对几种常见的鉴权方式整理一下。
目前我们常用的鉴权有四种：
- HTTP Basic Authentication
- session-cookie
- Token 验证
- OAuth(开放授权)
一.HTTP Basic Authentication
这种授权方式是浏览器遵守graph.qq.com/oauth2.0/show?which=Login&display=pc&response_type=code&client_id=100270989&redirect_uri=graph.qq.com/oauth2.0/show?which=Login&display=pc&response_type=code&client_id=100270989&redirect_uri=passport.csdn.net/account/login?oauth_provider=QQProvider&state=test
这个url地址我们可以看见Auth2.0常见的几个参数：
response_type，返回类型
client_id，第三方应用id,由授权服务器（qq）在第三方应用提交时颁发给第三方应用。
redirect_uri，登陆成功重定向页面
oauth_provider，第三方授权提供方
state，由第三方应用给出的随机码
第二步. 返回用户凭证（code），并返回一个凭证（code），当用户点击授权并登陆后，授权服务器将生成一个用户凭证（code）。这个用户凭证会附加在重定向的地址redirect_uri的后面
passport.csdn.net/account/login?code=9e3efa6cea739f9aaab2&state=XXX
第3步. 请求授权服务器授权:
经过第二部获取code后后面的工作就可以交给后台去处理的，和用户的交互就结束了。接下来我的需要获取Access Token，我们需要用他来向授权服务器获取用户信息等资源。
第三方应用后台通过第二步的凭证（code）向授权服务器请求Access Token，这时候需要以下几个信息：
- client_id 标识第三方应用的id，由授权服务器（Github）在第三方应用提交时颁发给第三方应用
- client_secret 第三方应用和授权服务器之间的安全凭证，由授权服务器（Github）在第三方应用提交时颁发给第三方应用
- code 第一步中返回的用户凭证redirect_uri 第一步生成用户凭证后跳转到第二步时的地址
- state 由第三方应用给出的随机码
第四步. 授权服务器同意授权后，返回一个资源访问的凭证（Access Token）。
第五步. 第三方应用通过第四步的凭证（Access Token）向资源服务器请求相关资源。
第六步. 资源服务器验证凭证（Access Token）通过后，将第三方应用请求的资源返回。
从用户角度来说，第三方授权可以让我们快速的登陆应用，无需进行繁琐的注册,同时不用记住各种账号密码。只需要记住自己常用的几个账号就ok了。
从产品经理的角度来所，这种授权方式提高用户的体验满意度。另一方面可以获取更多的用户。
总结：
授权方式多种多样，主要还是要取决于我们对于产品的定位。如果我们的产品只是在企业内部使用，token和session就可以满足我们的需求，如果是面向互联网的大众用户，那么第三方授权在用户体验度上会有一个很大的提升。
还是那句话，上面可能有很多‘通假字'勿怪，我写作的目的一方面是希望和大家分享我掌握的点点滴滴，另一方面也是梳理一下掌握的知识。
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持易盾网络。
本文共计1265个文字，预计阅读时间需要6分钟。
在最新重构公司产品前端代码时，我们移除了原有的session-cookie授权方式，转而采用token授权。以下是一些常见的授权方式整理：
1. HTTP Basic认证：基于用户名和密码的简单文本传输，安全性较低，不推荐用于敏感信息传输。
2.OAuth 2.0：一种授权框架，允许第三方应用访问服务器资源。它支持多种授权类型，如密码、授权码、客户端凭证等。
3.JWT (JSON Web Tokens)：一种用于在网络应用之间安全传输信息的简洁、自包含的格式。JWT包含一个签名，可用于验证其完整性和真实性。
4.API Key：为特定应用或用户分配一个密钥，用于访问API时的身份验证。
以上几种方式各有优劣，需根据实际需求和安全要求选择合适的授权方式。
最近在重构公司以前产品的前端代码，摈弃了以前的session-cookie鉴权方式，采用token鉴权，忙里偷闲觉得有必要对几种常见的鉴权方式整理一下。
目前我们常用的鉴权有四种：
- HTTP Basic Authentication
- session-cookie
- Token 验证
- OAuth(开放授权)
一.HTTP Basic Authentication
这种授权方式是浏览器遵守graph.qq.com/oauth2.0/show?which=Login&display=pc&response_type=code&client_id=100270989&redirect_uri=graph.qq.com/oauth2.0/show?which=Login&display=pc&response_type=code&client_id=100270989&redirect_uri=passport.csdn.net/account/login?oauth_provider=QQProvider&state=test
这个url地址我们可以看见Auth2.0常见的几个参数：
response_type，返回类型
client_id，第三方应用id,由授权服务器（qq）在第三方应用提交时颁发给第三方应用。
redirect_uri，登陆成功重定向页面
oauth_provider，第三方授权提供方
state，由第三方应用给出的随机码
第二步. 返回用户凭证（code），并返回一个凭证（code），当用户点击授权并登陆后，授权服务器将生成一个用户凭证（code）。这个用户凭证会附加在重定向的地址redirect_uri的后面
passport.csdn.net/account/login?code=9e3efa6cea739f9aaab2&state=XXX
第3步. 请求授权服务器授权:
经过第二部获取code后后面的工作就可以交给后台去处理的，和用户的交互就结束了。接下来我的需要获取Access Token，我们需要用他来向授权服务器获取用户信息等资源。
第三方应用后台通过第二步的凭证（code）向授权服务器请求Access Token，这时候需要以下几个信息：
- client_id 标识第三方应用的id，由授权服务器（Github）在第三方应用提交时颁发给第三方应用
- client_secret 第三方应用和授权服务器之间的安全凭证，由授权服务器（Github）在第三方应用提交时颁发给第三方应用
- code 第一步中返回的用户凭证redirect_uri 第一步生成用户凭证后跳转到第二步时的地址
- state 由第三方应用给出的随机码
第四步. 授权服务器同意授权后，返回一个资源访问的凭证（Access Token）。
第五步. 第三方应用通过第四步的凭证（Access Token）向资源服务器请求相关资源。
第六步. 资源服务器验证凭证（Access Token）通过后，将第三方应用请求的资源返回。
从用户角度来说，第三方授权可以让我们快速的登陆应用，无需进行繁琐的注册,同时不用记住各种账号密码。只需要记住自己常用的几个账号就ok了。
从产品经理的角度来所，这种授权方式提高用户的体验满意度。另一方面可以获取更多的用户。
总结：
授权方式多种多样，主要还是要取决于我们对于产品的定位。如果我们的产品只是在企业内部使用，token和session就可以满足我们的需求，如果是面向互联网的大众用户，那么第三方授权在用户体验度上会有一个很大的提升。
还是那句话，上面可能有很多‘通假字'勿怪，我写作的目的一方面是希望和大家分享我掌握的点点滴滴，另一方面也是梳理一下掌握的知识。
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持易盾网络。