基于令牌的身份验证:应用程序与服务器

在软件开发中,这些术语非常繁重,因此,如果不将重点放在非常具体的上下文中,就很难确定确切的含义。请记住,即使是身份验证也可以看作是一个非常广泛的上下文。

我将把您提议的工作流程改为:

1. 用户通过提供一组 用户凭据 _{(我们不必一直使用密码,请参阅 passwordless authentication 出于好奇)。}
2. 这个 授权服务器 验证用户身份,如果有效,则发出访问令牌。
3. 这个 客户 用户从中启动进程的应用程序接收并存储已颁发的访问令牌。
4. 这个 客户 应用程序调用 资源服务器 使用访问令牌以获取用户关联的资源。

该死,现在我们有了更多的术语,但让我们通过提供一些定义来解决这个问题。

首先,更通用的:

客户 :从服务器获取信息以供本地使用的应用程序。

资格证书 :用户名、密码、电子邮件地址是通信方生成或获取安全令牌的各种方式。

(来源: Auth0 Identity Glossary

然后在上下文中定义 OAuth 2.0 和/或 OpenID Connect :

授权服务器 :成功验证资源所有者并获得授权后,向客户端颁发访问令牌的服务器。

资源服务器 :托管受保护资源的服务器,能够使用访问令牌接受和响应受保护资源请求。

客户 :代表资源所有者并在其授权下发出受保护资源请求的应用程序。术语“客户端”并不意味着任何特定的实现特征(例如,应用程序是否在服务器、桌面或其他设备上执行)。

(来源: RFC 6749 )

尝试定义应用程序甚至没有什么用处,但我们应该从其他定义中得出以下结论:

• 正如您所说,客户端可以从web、移动到事件服务器端应用程序。
• 授权服务器和资源服务器的角色可以由同一组件扮演,例如,Web API的端点受HTTP基本身份验证保护,可用于将一对用户名/密码凭据与访问令牌交换,然后所有剩余的API端点都会受到保护,仅当您提供该访问令牌时才允许访问。

最后,最后一个要澄清的问题是,访问令牌的创建需要在服务器端进行,因为令牌的创建将伴随着某种机制,该机制将确保令牌不会被篡改,并且实际上是由一个非常熟悉的实体创建的。对于以下情况 JWT's 该机制包括对令牌进行签名,这是通过让服务器知道其他人都不知道的秘密来实现的。