API身份验证和授权介绍

SAP小白kenny

已于 2022-04-19 09:06:18 修改

阅读量1.5w

点赞数 29

分类专栏：接口文章标签： http

于 2022-04-15 09:44:29 首次发布

本文链接：https://blog.csdn.net/weixin_42646630/article/details/124173486

版权

接口专栏收录该内容

40 篇文章

订阅专栏

一、前言

用户通常需要注册API KEY或者其他验证方法，才能使用你的服务，一般我们会用到一下集中验证方式

API Keys
Basic Auth
HMAC
OAuth

身份验证：指证明正确的身份，

授权：允许的动作

API可能会对您进行身份验证，但未授权您发出特定的请求

API缺乏安全性的后果

为什么API需要身份验证，API没有安全性，用户可以任意注册即可无限次访问和调用API，且没有请求与特定用户数据关联的简单方法，就无法防止恶意用户的恶意请求等。

二、API Key

API Key是一个长字符串，通常包含在URL或者header里面，主要作用于api调用员的验证，api key也可能和您注册的特定应用程序关联。

api 可能同时提供公钥和密钥，公钥包含在请求里面，密钥则是像密码，仅在服务器到服务器的连接时使用到。

三、Basic Auth

基本身份验证，使用此方法，发送usaname: passward放入header中，用户名和密码使用Base64编码，Base64是一种编码技术，将用户名和密码转换为一组64的字符串，确保安全传输，如下：

使用Basic Auth的验证api也将使用https，意味着消息内容在http传输协议中加密，没有的话，用户会很简单的理解用户名和密码

四、OAuth 2.0

OAuth 2.0是一种用户验证和授权用户的流行方法，此方法依赖于身份验证服务器和API服务器进行通信以授予访问权限，OAuth有几种变体，即"one-legged OAuth" 和"three-legged OAuth"，如果没有敏感数据需要保护，使用前一个，如果你有敏感信息需要保护，则使用"three-legged OAuth"，这样的话会有三个组进行交互：

认证服务器；资源服务器(api服务器)；用户或应用；

首先，消费者在应用程序上，将密钥和机密发给身份验证服务器，如果验证成功，会返回令牌，将令牌打包到请求的请求的响应重定向(302)的查询参数中，重定向将用户的请求指向资源服务器(API服务器)。

然后用户向资源服务器发出请求，将访问令牌添加到API请求的header中，其单词为Bearver，后跟令牌字符串。api服务器会检查请求中的令牌，并决定是否对用户进行身份验证。

访问令牌不仅为用户提供身份验证，而且还定义的用户如何使用api的权限，

如果你需要提供OAuth2.0的验证给外部用户，你需要提供一下信息：

如何获取api密钥；

如何验证请求；

与无效身份验证有关的信息；

身份验证的敏感性；

令牌到期时间；

Twitter

总结：

OAuth2.0 就是可以通过身份验证，给予访问者一个临时令牌，根据令牌，可以在一段时间内直接访问服务。这种情况同时可以限制该账号的权限，而不是给予一个大的公共账号权限，而且用户也不可以自己修改密码。

token和passward比较

1、令牌是短期的，到期自动失效，用户无法修改，密码是长期，风险更大。

2、令牌可以配数据提供者取消，密码的话更繁琐。

3、令牌的话权限管控更精细。

OAuth的四种授权方式

Authorization-code
implicit
passward
Client Credentials

注意，不管哪一种授权方式，第三方应用申请令牌之前，都必须先到系统备案，说明自己的身份，然后会拿到两个身份识别码：客户端 ID（client ID）和客户端密钥（client secret）。这是为了防止令牌被滥用，没有备案过的第三方应用，是不会拿到令牌的。

1、Authorization-code

第三方应用先申请一个授权码，然后根据该码和获取令牌。适用前后端分离的。

第一步，A 网站提供一个链接，用户点击后就会跳转到 B 网站，授权用户数据给 A 网站使用。下面就是 A 网站跳转 B 网站的一个示意链接。

https://b.com/oauth/authorize?
  response_type=code&
  client_id=CLIENT_ID&
  redirect_uri=CALLBACK_URL&
  scope=read

上面 URL 中，response_type参数表示要求返回授权码（code），client_id参数让 B 知道是谁在请求，redirect_uri参数是 B 接受或拒绝请求后的跳转网址，scope参数表示要求的授权范围（这里是只读）。

第二步，用户跳转后，B 网站会要求用户登录，然后询问是否同意给予 A 网站授权。用户表示同意，这时 B 网站就会跳回redirect_uri参数指定的网址。跳转时，会传回一个授权码，就像下面这样。

https://a.com/callback?code=AUTHORIZATION_CODE

上面 URL 中，code参数就是授权码

第三步，A 网站拿到授权码以后，就可以在后端，向 B 网站请求令牌。

https://b.com/oauth/token?
 client_id=CLIENT_ID&
 client_secret=CLIENT_SECRET&
 grant_type=authorization_code&
 code=AUTHORIZATION_CODE&
 redirect_uri=CALLBACK_URL

上面 URL 中，client_id参数和client_secret参数用来让 B 确认 A 的身份（client_secret参数是保密的，因此只能在后端发请求），grant_type参数的值是AUTHORIZATION_CODE，表示采用的授权方式是授权码，code参数是上一步拿到的授权码，redirect_uri参数是令牌颁发后的回调网址。

第四步，B 网站收到请求以后，就会颁发令牌。具体做法是向redirect_uri指定的网址，发送一段 JSON 数据。

{    
  "access_token":"ACCESS_TOKEN",
  "token_type":"bearer",
  "expires_in":2592000,
  "refresh_token":"REFRESH_TOKEN",
  "scope":"read",
  "uid":100101,
  "info":{...}
}

上面 JSON 数据中，access_token字段就是令牌，A 网站在后端拿到了。

2、implicit

如果是纯前端应用，没有后端。令牌就必须在前端。允许直接向前端颁发令牌，没有授权码这个过程。

第一步，A 网站提供一个链接，要求用户跳转到 B 网站，授权用户数据给 A 网站使用。

https://b.com/oauth/authorize?
  response_type=token&
  client_id=CLIENT_ID&
  redirect_uri=CALLBACK_URL&
  scope=read

上面 URL 中，response_type参数为token，表示要求直接返回令牌。

第二步，用户跳转到 B 网站，登录后同意给予 A 网站授权。这时，B 网站就会跳回redirect_uri参数指定的跳转网址，并且把令牌作为 URL 参数，传给 A 网站

https://a.com/callback#token=ACCESS_TOKEN

上面 URL 中，token参数就是令牌，A 网站因此直接在前端拿到令牌。

注意，令牌的位置是 URL 锚点（fragment），而不是查询字符串（querystring），这是因为 OAuth 2.0 允许跳转网址是 HTTP 协议，因此存在"中间人攻击"的风险，而浏览器跳转时，锚点不会发到服务器，就减少了泄漏令牌的风险。

这种方式把令牌直接传给前端，是很不安全的。因此，只能用于一些安全要求不高的场景，并且令牌的有效期必须非常短，通常就是会话期间（session）有效，浏览器关掉，令牌就失效了。

3、Passward

如果你高度信任某个应用，RFC 6749 也允许用户把用户名和密码，直接告诉该应用。该应用就使用你的密码，申请令牌，这种方式称为"密码式"（password）。

第一步，A 网站要求用户提供 B 网站的用户名和密码。拿到以后，A 就直接向 B 请求令牌。

https://oauth.b.com/token?
  grant_type=password&
  username=USERNAME&
  password=PASSWORD&
  client_id=CLIENT_ID

上面 URL 中，grant_type参数是授权方式，这里的password表示"密码式"，username和password是 B 的用户名和密码。

第二步，B 网站验证身份通过后，直接给出令牌。注意，这时不需要跳转，而是把令牌放在 JSON 数据里面，作为 HTTP 回应，A 因此拿到令牌。

这种方式需要用户给出自己的用户名/密码，显然风险很大，因此只适用于其他授权方式都无法采用的情况，而且必须是用户高度信任的应用。

4、Client Credential

最后一种方式是凭证式（client credentials），适用于没有前端的命令行应用，即在命令行下请求令牌。

第一步，A 应用在命令行向 B 发出请求。

https://oauth.b.com/token?
  grant_type=client_credentials&
  client_id=CLIENT_ID&
  client_secret=CLIENT_SECRET

上面 URL 中，grant_type参数等于client_credentials表示采用凭证式，client_id和client_secret用来让 B 确认 A 的身份。

第二步，B 网站验证通过以后，直接返回令牌。

这种方式给出的令牌，是针对第三方应用的，而不是针对用户的，即有可能多个用户共享同一个令牌。

令牌的使用

此时，每个发到 API 的请求，都必须带有令牌。具体做法是在请求的头信息，加上一个Authorization字段，令牌就放在这个字段里面。

curl -H "Authorization: Bearer ACCESS_TOKEN" \
"https://api.b.com"

令牌的有效期到了，如果让用户重新走一遍上面的流程，再申请一个新的令牌，很可能体验不好，而且也没有必要。OAuth 2.0 允许用户自动更新令牌。

具体方法是，B 网站颁发令牌的时候，一次性颁发两个令牌，一个用于获取数据，另一个用于获取新的令牌（refresh token 字段）。令牌到期前，用户使用 refresh token 发一个请求，去更新令牌。


https://b.com/oauth/token?
  grant_type=refresh_token&
  client_id=CLIENT_ID&
  client_secret=CLIENT_SECRET&
  refresh_token=REFRESH_TOKEN

上面 URL 中，grant_type参数为refresh_token表示要求更新令牌，client_id参数和client_secret参数用于确认身份，refresh_token参数就是用于更新令牌的令牌。

B 网站验证通过以后，就会颁发新的令牌。

写到这里，颁发令牌的四种方式就介绍完了。下一篇文章会编写一个真实的 Demo，演示如何通过 OAuth 2.0 向 GitHub 的 API 申请令牌，然后再用令牌获取数据。