基本身份验证、SAML、密钥、OAuth、JWT 和令牌 Quicky

基本身份验证

SAML

OAuth 2.0

API 密钥

资源

以下是我上周了解到的有关安全的知识。

如果有人半夜把我叫醒，告诉我休斯顿出了问题，SAML而我又觉得 SAML 就像我最近梦到的一艘克瑞翁人的宇宙飞船，我一定会打开这张纸条，发现它实际上是一种身份验证和授权机制，而不是一艘克瑞翁人的宇宙飞船。又或许，它就是？;))。让我们深入挖掘，一探究竟！

安全是一个术语繁多的话题，感觉需要一本安全词典。以下是一些安全领域的主要术语和概念。

注意！您已经知道什么是安全，您只需要将这些令人生畏的术语与您在现实生活中已经了解的安全知识联系起来！

醒醒！什么是 SAML！

安全性主要关乎正确性。您需要确定与您通信的人员/服务是谁（身份验证）。并且您需要验证该个人服务是否只执行了其被允许执行的操作（授权） 。

我们将快速扫描以下术语：

1. Basic Authentication => When mama and papa thought about security.
2. SAML => When large corporates thought about security.
3. OAuth 2.0 => The foster child of mama, papa, and large corporates.
4. JWT => The startup kid buying a coffee paying with json
5. Tokens => Trading sheep for online services.
6. Authorization Bearer: <token> => The all mighty header.
7. Keys and $$$ => Give me the bottom line how do I make $$$ out of security.

基本身份验证

这是最基本的操作。你要求用户或服务提供一些只有他自己知道的信息来证明他的身份。我们使用用户名和一些秘密信息，也就是密码。

授权：基本 Base64（用户，密码）

基本身份验证没有指定需要加密详细信息，只需对其进行 Base64 加密即可。因此，它是明文。

明文！使用 https 加密

但由于它是明文，所以你需要加密，否则任何在线的人或任何有权访问该服务的人都能看到你的凭证。所以你使用加密，https。

SAML

我们完成了协议1的基本身份验证。协议2。SAML（安全断言标记语言）。

身份验证和授权

想象一下，如果它是另一种身份验证协议（例如基本身份验证），但它也支持授权。这意味着它还会告诉你可以做什么。

XML

SAML 起源于 XML 为王的时代，因此 SAML 协议使用 XML 传递凭证和授权数据也就不足为奇了。

各方

在 SAML 中我们有两方。

1. 服务提供商，您可以从服务提供商处购买咖啡。
2. 身份提供者，您通过身份提供者证明您是谁，这与购买咖啡有很大不同，即使它闻起来真的很好！

服务提供商

这是杂货店，它对向我出售杂货感兴趣，而不是对身份管理感兴趣，因此它将使用身份提供商来识别我，以便授权和验证我。

身份提供者

身份提供者负责管理身份以及他们被允许做的事情。

提供标准 SSO

SAML 提供了标准SingleSignOn，因此您可以使用同一个身份登录多个网站，这很酷，就像您使用 Google 登录不同的服务一样，只是这次使用的是 SAML 协议。您已经了解 SAML 的含义了。

使用数字签名的 XML 交换身份验证

通过数字签名，我们可以证明谁签署了您的身份验证数据。

复杂的

最后但同样重要的是，SAML 比 OAuth 2.0 等现代 SSO 方法更复杂。所以，我们还是先了解一下 OAuth 2.0 吧。

OAuth 2.0

你可能会问，1.0 版本怎么样？它更复杂，所以我们迁移到了 2.0，在 2.0 版本中，我们需要执行的授权操作更少。

非身份验证

我再说一遍，OAuth2.0 不是一个身份验证协议，它只是用于授权。但这并不意味着我们不使用 OAuth 进行身份验证，OpenId是一个基于 OAuth2.0 的协议，用于身份验证。

授权

您使用 oauth2.0 允许服务检查您或服务是否被授权执行操作。

HTTP

OAuth 内部不加密任何内容，它不要求您，也不强制您使用 https 或其他加密机制，但您可能会发现自己正在使用这些，但请记住，协议本身没有内置 https 或加密。

令牌是新的凭证

还记得凭证吗？用户名/密码？忘掉它们吧，我们现在用令牌代替。这是一样的，你有一个类似于用户名的密钥，还有一个类似于密码的密钥。虽然令牌和用户名密码几乎一样，但令牌不会说用户名和密码。

从 1.0 开始无需对每个呼叫进行签名

在 OAuth1.0 中，您需要对其进行签名，而调用 oauth 2.0 会使用提供给您的令牌来简化它 - 您只需传递此令牌，无需重新签名。

访问令牌和/或刷新令牌

您使用访问令牌和/或刷新令牌来更新您的访问令牌。服务。

获取访问令牌（刷新令牌）

因此，基本上要获取新的访问令牌，您只需使用输入刷新令牌调用 getAccessToken 即可获取新的访问令牌来访问服务。

授权：持有人

在基本身份验证、OAuth 以及无论您去哪里，您都会看到此标头：

Authorization: Bearer <access token>

您只需始终使用此标头来访问您的服务。

智威汤逊

这是镇上新来的孩子，大家都觉得他好可爱！为什么呢？因为这个伟大的新发明：

你不仅在安全数据中放入了身份验证授权，还放入了一些真实数据！例如，“我可以免费喝杯咖啡！——一个声明”。这是21世纪最伟大的发明之一（或者说不是:)。

OAuth 2.0 的扩展

JWT 只是 OAuth 2.0 的一个扩展，所以它就像一个养子。

带有声明的访问令牌

因此，您可以使用 JWT 指定您可以获得一杯免费咖啡，这是“令人兴奋”的声明部分。

授权：持有人

是的，我们再次使用无聊的Authorization: Bearer <JWT>

标头、有效载荷、签名

JWT 中有 3 个部分

1. 标头（元数据）
2. 有效载荷（咖啡）
3. 签名（是我）

HMAC-SHA256

这是用于对消息进行哈希处理的协议。

使用密钥进行哈希运算来计算签名

HMAC - 使用密钥进行哈希运算以生成签名。

从客户端重新传递的无状态数据 API 数据

因此，JWT 是关于无状态的，你将数据从这里传递到那里，然后返回，所有这些都在 JWT 中

而不是服务器上的传统会话

您在 JWT 中传递数据，因此您不需要在服务器中存储数据。

用法

我们将 JWT 用于什么？

验证

我们用它来进行身份验证；）

安全信息交换

我们用它来传递安全信息！

使用公钥/私钥签名，验证内容未被篡改

这是因为我们对数据进行了签名，所以我们知道它没有被篡改！

API 密钥

机器的用户名密码。就像比特币和美元一样。

识别呼叫者/应用程序

您可以识别谁是呼叫者应用程序，因为您为每个呼叫者提供了自己的密钥。

货币化 API

现在您知道是谁给您打电话了——您可以向他收取使用您的 API 的费用！（他使用 API 密钥访问您，他应该为此付费）。

资源

https://tomer-ben-david.github.io