对现代 Web 应用程序进行身份验证的最常用方法是什么? [英] What is the most common way to authenticate a modern web app?
问题描述
我正在使用 Spring、Spring Security 编写 Web 应用程序 (REST API).现在我有基本身份验证和使用用户名、密码和角色的非常简单的授权.我想改进安全层，但我没有这方面的经验.
I'm writing a web app (REST API) using Spring, Spring Security. Right now I have Basic authentication and a really straightforward authorization using username, password and roles. I want to improve the security layer but I have no experience with this.
当我查看邮递员寻找可能的身份验证方法并在谷歌上搜索时，我看到有以下选项:
When I had looked at postman for possible authentication methods and searched on google I've seen there are these options:
- API 密钥
- 不记名令牌
- 基本身份验证
- 摘要验证
- OAuth 1.0
- OAuth 2.0
- Hawk 验证
- AWS 签名
- NTLM 身份验证
Digest、Hawk、AWS 和 NTLM 似乎是非常具体的案例，所以我省略了它们.
Digest, Hawk, AWS and NTLM seem to be really specific cases so I omit them.
我只听说了一些关于 API 密钥、不记名令牌和 OAuth 1.0\2.0 的一般信息，但 OAuth 1.0 似乎已经过时了或其他什么(我的意思是，2.0 版存在是有原因的).
I've heard just some general information about API key, Bearer Token and OAuth 1.0\2.0, but OAuth 1.0 seems to be outdated or something (I mean, there is a reason for version 2.0 to exist).
因此，我似乎有 3 种可能的变体:
So as a result it seems that I have 3 possible variants:
- API 密钥
- 不记名令牌
- OAuth 2.0
我的假设正确吗?现代网络应用中最广泛使用的安全层案例是什么?
Is my assumption correct? What is the most widely-used case in modern web apps for security layer?
我不要求对每个案例进行完整描述，只是一般性建议，也许还有一些链接\资源可供查看.
I don't ask for a full description for each case, just general recommendations, maybe some links\resources to look at.
我应该专注于什么?
您发现我的描述\解释中有哪些错误?
What mistakes in my description\explanation do you see?
推荐答案
就 Web 应用程序而言，Web 应用程序请求应该有状态，session 是最常见的有状态方式.
As far as web application is concerned web application request should have state, session is the most common way to have state.
当我们考虑 REST API 的请求时，首选是无状态的，但要验证和识别用户或客户端，OP 提到的方法有很多.
And when we consider REST API's requests are preferred to be stateless, but to authenticate and identify user or client there are lot of ways as OP mentioned.
在基本身份验证中，用户发送由 base64 编码器编码的凭据.
凭据在具有基本前缀的 Authorization 标头中发送，如下所示."基本"+ encodeUsingBase64(username+":"+password)
In Basic authentication user sends his credential encoded by base64 encoder.
Credentials are sent in Authorization header with Basic prefix as given below.
"Basic "+ encodeUsingBase64(username+":"+password)
如果您的 REST API 受基本身份验证保护，则不属于应用程序的用户(不在服务器数据库中的用户)无法访问受保护的资源.
理想情况下，基本身份验证仅适用于应用程序用户
If Your REST API is secured by Basic auth, a user who is not part of application(a user who is not present in database of server) can't access secured resources.
Ideally Basic auth is for only application users
JSON 网络令牌 (JWT) 是一种开放标准 (RFC 7519)，其中服务器与客户端共享数字签名令牌，应用程序用户和非应用程序用户都可以使用它，服务器端逻辑从令牌的有效负载并使用它的数据库条目进行验证以进行授权.这里 JWT 用例不受某些实现的限制，有效载荷也可以包含授权信息.单点登录是当今 JWT 广泛使用的一项功能.
JSON Web Token (JWT) is an open standard (RFC 7519) where a server shares a digitally signed token with the client, it can be used by both application users and non application users with server side logic which extracts user information from the payload of token and validates with it's database entries for authorization. Here with JWT use case is not limited in some implementation payload can contain authorization information as well. Single Sign On is a feature that widely uses JWT nowadays.
与基本认证相比
基本身份验证是一个身份验证步骤，其中将在每个请求中发送完整的凭据(包括密码).
Basic authentication is a authentication step where complete credential(including password) will be sent in each request.
JWT 是认证后步骤，其中经过身份验证的用户会收到一个不包含密码信息的签名令牌.
JWT is a post authentication step, where a authenticated user receives a signed token which doesn't contains password information.
它没有标准，可能是随机生成的字符串发给API的用户.不同发行人的用例会有所不同.在这里
It has no standards, it might be randomly generated string issued to the users of API. Use case will be different for different issuer. It is well discussed here
Oauth2 是一个不同的类别.一句话这不是为了保护所有应用程序API的安全，而是在用户同意的情况下向第三方应用程序提供对用户资源的访问权限>.
Oauth2 is a different category. In one sentense it is not about securing all application API's but providing access to user resource to the third party applications with the consent of user.
主要有4个部分.让我们以 Facebook 为例
1. 授权服务器 [Facebook]
2.资源服务器[Facebook和资源将成为您的个人资料]
3.客户端[堆栈溢出、Quora、糖果粉碎、地铁冲浪等]
4. 资源所有者 [您(如果经过身份验证)]
it has mainly 4 parts. Lets take example of Facebook
1. Authorization Server [Facebook]
2. Resource server [Facebook and resource will be your profile]
3. Client [Stack overflow, Quora, Candy crush, Subway Surfer etc]
4. Resource owner [You (If Authenticated)]
资源服务器可能由安全和不安全的 API 组成.为了访问安全 API 的客户端，需要授权服务器发布的 access_token.发出的 access_token 是一个随机字符串，也与关联的用户、范围(read、read_profile_info、write)一起存储在授权服务器数据库中.
Resource server may consists of both secured and unsecured API's. For accessing secured API's Client need access_token which is issued by Authorization server. access_token issued is a random string and is also stored in authorization server database along with the associated user, scope(read, read_profile_info, write).
此处资源所有者(您)同意授权服务器授予范围的 access_token(read,read-profile,post-to-my-timeline 等)到客户端(Quora,StackOverflow,Candy-Crush 等)
Here Resource owner(You) giving consent to the Authorization server to grant a access_token of scope(read,read-profile,post-to-my-timeline etc) to the Client(Quora,StackOverflow,Candy-Crush etc)
- 收到的access_token 将同时具有身份验证和授权.因此，为 access_token 提供特定范围会很有帮助.
(假设堆栈溢出访问基本个人资料信息，糖果粉碎访问更多信息，包括代表您发布的范围) - access_token 的生命周期，refresh_token 的 grant_type.
访问令牌的生命周期有限.如果客户端应用程序需要在单个访问令牌的生命周期之外访问 Resource，它可以获得刷新令牌.刷新令牌允许客户端应用程序获取新的访问令牌.
授权类型:(授权码、隐式、密码、客户端凭据、刷新令牌)
注意:
Oauth2 Auth 服务器不仅适用于 facebook 和 Google 等应用程序，而且您的应用程序可以设置 oauth2 服务器，并且您可以为您的客户提供 access_token(将您的 API 与他们的应用程序集成)具有不同的范围，基于订阅的生命周期/许可证.
Note:
Oauth2 Auth server not only for applications like facebook and Google but also Your application can have oauth2 server set up, and you can provide your clients access_token (to integrate your API with their application) with different scope, lifespan based on subscription/license.
我没有研究过摘要身份验证.参考此线程了解更多详情
I have not worked on digest auth. Refer this thread for more details
上述任何身份验证都与传输层安全性 (SSL) 相关，以确保您在后续请求中传递的凭据/令牌不会被捕获为纯文本.
Any of the above authentication is concerned transport layer security(SSL) is important to ensure credentials/token you pass in subsequent requests is not captured as plain text.
SSL 证书由服务器发送给客户端.(任何向服务器发出请求的客户端都会收到 SSL 副本.没有限制，任何客户端都可以接收 SSL 证书).
SSL certificate is sent by server to client.(Any client which makes request to server receives SSL copy. There is no restriction, any client can receive SSL certificate).
但在 X.509 客户端证书的情况下，使用服务器 SSL 证书创建并与客户端秘密共享.客户端使用 X.509 证书与服务器通信.这里需要注意的重要一点是，对于不同的客户端，将生成不同的客户端证书来识别每个客户端.X.509 确保的是
But in case of X.509 client certificate is created using server SSL certificate and it is secretly shared with the client. Client uses X.509 certificate to communicate with server. Here one important point to be noted that for different clients different client certificate will be generated to identify each client. What X.509 ensures is
安全性(没有客户端证书的人无法访问 API)
Security(Who don't have client certificate can't access API's)
身份(服务器可以根据证书主题识别客户端)
Identity(server can identify client based on certificate subject)
这篇关于对现代 Web 应用程序进行身份验证的最常用方法是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
