Sec快速指南：基本身份验证，SAML，密钥，OAuth，JWT和tokens

SAML是太空船还是一种咖啡？

安全主要关乎正确性。你想确定你与谁交谈的人/服务是（认证）。而且你想验证那个人/服务只是在做他们被允许做的事情（授权）。

我们将迅速扫描以下条款：

基本认证

SAML

OAuth 2.0

JWT

Tokens

Authorization Bearer

Keys and Money

这是最基本的。您只需向用户或服务部门提供他们知道的内容以证明其身份。我们使用用户名和密码，即密码。

基本认证

这是最基本的。您只需向用户或服务部门提供他们知道的内容以证明其身份。我们使用用户名和密码，即密码。

授权：基本Base64（用户，合格）

基本认证没有指定你需要加密细节，你只需要base64它们。所以这是明文。

明文！使用HTTPS进行加密

但是，因为它是明文，所以你想加密它，否则任何有线或任何有权访问服务的人都可以看到你的凭证。所以你应该使用加密和HTTPS。

SAML

我们完成了协议编号1，基本认证。协议编号2是 SAML（安全断言标记语言）。

认证和授权

把它看作另一种认证协议（如基本认证），但它也支持授权。这意味着它也会告诉你你被允许做什么。

XML

SAML起源于XML为王的时代，因此SAML协议将数据传递给XML凭证和授权并不奇怪。

Parties

在SAML中，我们有两个Parties。

服务提供商： 您可以从服务提供商处购买咖啡。

身份提供商： 您可以证明您与身份提供商的合作关系，与购买咖啡完全不同，即使它的味道真的很好！

服务提供者

这是杂货店，它有兴趣向我推销一些东西，而不是关于身份管理，所以它会使用身份提供者来识别我，以便授权和验证我。

身份提供者

身份提供者全都是关于管理身份和允许他们做什么的。

提供标准SSO

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

认证与数字签名的XML交换

通过数字签名，我的意思是我们可以证明谁是签名认证数据的人。

复杂

最后但并非最不重要的是，SAML比现代SSO方法（如OAuth 2.0）更复杂。那么我们来看看OAuth 2.0吧？

OAuth 2.0

你问1.0什么？ 这更复杂，所以我们转到2.0，我们需要为我们的授权进行更少的操作。

NOT身份验证

我重复OAuth2.0不是一个身份验证协议，它全部是关于授权。这并不意味着我们不使用OAuth进行身份验证，但是，因为 OpenId是OAuth2.0之上的协议，用于身份验证。

授权

您使用OAuth2.0来允许服务检查您或服务是否有权执行操作。

HTTP

OAuth不会在内部对任何内容进行加密（也不会强制您加密文件），它不会强制您使用HTTPS或其他加密机制，但您可能会发现自己正在使用这些机制，因此请记住内部没有HTTP或加密到OAuth协议本身。

Tokens是新的证书

记住凭据（用户名/密码）？忘记它们，我们现在使用Tokens，它们在相同的大前提下运行。你有一些关键就像你的用户名，你有一些密码就像你的密码。 所以，虽然Tokens不使用术语“用户名”和“ 密码”，但它几乎是一回事。

从1.0更改：无需签署每个呼叫

在OAuth1.0中，您需要通过电话进行签名。OAuth 2.0使用为您提供的Tokens简化了这一操作 - 您所做的只是传递此Tokens，无需辞职。

访问Tokens和/或刷新Tokens

您使用访问Tokens和/或刷新Tokens以更新您的访问权限 token.services。

getAccessToken（refreshToken）

所以，基本上，要获得一个新的访问Tokens，您只需getAccessToken 使用输入刷新Tokens调用 以获取新的访问Tokens以访问服务。

Authorization Bearer

在基本身份验证，OAuth和任何地方，你会看到这个头文件：

Authorization: Bearer

你 总是使用这个头来为你的服务的访问。

JWT

这是城里新来的孩子，每个人都认为他太可爱了！这是为什么？由于这个伟大的新发明，您不仅将认证和授权置于安全数据中，还将一些真实数据放入！例如：

OAuth 2.0的扩展

JWT只是OAuth 2.0的扩展。

访问Token与索赔

您可以通过JWT指定您可以获得免费咖啡; 这是“头脑风暴”的主张。

Authorization Bearer

是的，我们必须再次使用无聊 Authorization: Bearer

标头，有效载荷，签名

JWT有3个部件

Header (metadata)

Payload (coffee)

Signature (it's me)

HMAC-SHA256

这是用于哈希消息的协议。

用计算签名的秘密钥匙哈希

HMAC - 用密钥生成签名。

无状态数据和从客户端重新发送的API数据

因此，由于JWT是无状态的，因此当您将数据从这里传递到那里并返回时，全部都在JWT中。

而不是在服务器上的传统会话，您传递JWT中的数据，因此您不需要将数据存储在服务器上。

用法

我们使用JWT做什么？

认证

我们使用它进行身份验证。

安全的信息交换

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

用公钥/私钥签名以验证内容没有被篡改

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

API密钥

识别呼叫者/应用程序

您可以确定谁是调用者应用程序，因为您为每个调用者分配了自己的密钥。