认证(Authentication)
对某人身份信息的确认,通过某一凭证确认得知 “某人是谁!”
例:用户名/用户ID和密码
授权(Authorization)
当对某人完成身份确认后,获取某人能够访问资源的权限
例:信息、文件、数据等
API调用过程中有那些授权类型
-
No auth
请求不需要授权,无身份验证 -
API key
使用 API 密钥身份验证,即在请求标头或查询参数中将键值对发送到 API。
API Key是API的密钥,是访问API或网站的必要条件之一,它通常用于防止未经授权的访问。
Key ID:这是API Key的唯一标识符,用于在请求中识别特定的API Key。
Key Value:这是实际的API Key值,通常是一个长字符串,用于验证请求的来源。 -
Bearer Token
Bearer token允许使用例如JSON Web Token (JWT)的访问秘钥。
Bearer token常用于API的身份验证和授权,其中可能会包含用户的登录信息(如用户名、有效时间)。
服务器接收到请求后,验证用户的登录信息是否有效。如果登录信息有效,用户无需客户端多次登录才能访问不同的API资源。Bearer token的主要优点是简单易用、轻量级且易于集成到各种应用程序中。 -
JWT bearer
可以在Postman的编辑器中输入有效的payload,生成的JWT可以被添加到请求的header或query parameter中。- 其中用于JWT Token的算法:
- HS - HMAC with SHA
- RS - RSA (RSASSA-PKCS1-v1_5) with SHA
- ES - ECDSA with SHA
- PS - RSA (RSASSA-PSS) with SHA
- Secret - 与 HMAC-SHA 算法一起使用的Secret
- Base64 编码
- Payload - 以 JSON 格式输入 JWT 令牌的有效负载数据
- 其中用于JWT Token的算法:
-
Basic auth
在用户名和密码字段中输入您的 API 用户名和密码
在headers中向 API 传递一个表示用户名和密码值的 Base64 编码字符串,形式是:
Basic <Base64 encoded username and password>
- OAuth 1.0
OAuth1.0定义了三种角色:User、Service Provider、Consumer
+----------+ +----------+
| |--(A)- Obtaining a Request Token --------->| |
| | | |
| |<-(B)- Request Token & secret -------------| |
| | (Unauthorized) | |
| | | |
| | +--------+ | |
| |>-(C)-| -+-(C)- Directing ---------->| |
| | | -+-(D)- User authenticates ->| |
| | | | +----------+ | Service |
| Consumer | | User- | | | | Provider |
| | | Agent -+-(D)->| User | | |
| | | | | | | |
| | | | +----------+ | |
| |<-(E)-| -+-(E)- Request Token ------<| |
| | +--------+ (Authorized) | |
| | | |
| |--(F)- Obtaining a Access Token ---------->| |
| | | |
| |<-(G)- Access Token -----------------------| |
+----------+ +----------+
-
Consumer向Service Provider请求未授权 Request Token
-
Service Provider返回未授权Request Token和 secret,具体返回的参数为:oauth_token 和 oauth_token_secret
-
Consumer携带上一步的 oauth_token 以及 oauth_callback 等参数请求服务器
-
User authenticates
-
Service Provider将用户重定向回Consumer,并带回授权过的 Request Token 也就是 oauth_token
-
获取到授权 Request Token,再向Service Provider换取票据 accessToken
-
通过票据 accessToken 访问用户在资源服务器存储的受保护的资源
- OAuth 2.0
OAuth1.0定义了三种角色:User、Service Provider、Consumer。而OAuth2.0则定义了四种角色:Resource Owner、Resource Server、Client、Authorization Server
+----------+
| resource |
| owner |
| |
+----------+
^
|
(B)
+----|-----+ Client Identifier +---------------+
| -+----(A)-- & Redirection URI ---->| |
| User- | | Authorization |
| Agent -+----(B)-- User authenticates --->| Server |
| | | |
| -+----(C)-- Authorization Code ---<| |
+-|----|---+ +---------------+
| | ^ v
(A) (C) | |
| | | |
^ v | |
+---------+ | |
| |>---(D)-- Authorization Code ---------' |
| Client | & Redirection URI |
| | |
| |<---(E)----- Access Token -------------------'
+---------+ (w/ Optional Refresh Token)
(1)授权码模式
已使用微信登录游戏为例:
(2)客户端模式
客户端以自己的名义而不是用户的,向授权服务器进行验证。
举个例子:当我们的服务需要对接另一个服务时,我们的服务充当“客户端”向微信授权服务器进行认证。
在OAuth 2.0的客户端模式中,向授权服务器发送认证请求时client_id和client_secret是两个重要的参数。
client_id是用于在授权服务器上标识和认证客户端的ID。它是在客户端向授权服务器发起请求时,一起发送给授权服务器的。通过验证client_id,授权服务器可以确认请求来自哪个已注册的客户端。
client_secret是一个保密的字符串,用于验证客户端的身份。它是与client_id相对应的,且在授权服务器上注册应用程序时获得。