基于 OAuth 和基于 Token 的身份验证有什么区别? [英] What is the difference between OAuth based and Token based authentication?

问题描述

我认为 OAuth 基本上是基于令牌的身份验证规范，但大多数时候框架的行为似乎它们之间存在差异.例如，如下图所示，

解决方案

这是一个很好的问题——关于令牌和 OAuth 存在很多混淆.

首先，当您提到 OAuth 时，您可能指的是 OAuth2 标准.这是 OAuth 协议的最新版本，也是大多数人在说OAuth"时专门谈论的内容.

OAuth 协议支持多种不同类型的身份验证和授权(准确地说是 4 种).

其次，OAuth 协议通过令牌对用户进行身份验证来工作.这里的想法是这样的:

不是让您的用户在每个请求中都将他们的实际凭据发送到您的服务器(就像他们使用基本身份验证一样，用户针对每个请求将他们的用户名/密码发送到服务器)，而使用 OAuth，您首先交换您的用户'token' 的凭据，然后根据此 'token' 对用户进行身份验证.

OAuth 的理念是，通过要求用户减少通过网络传递机密凭据的频率，可以减少坏事的发生.(无论如何，这就是这个想法.)

现在，令牌在这里发挥作用:OAuth 规范是围绕令牌的概念构建的，但没有具体说明令牌是什么.

在最一般"的意义上，令牌只是一个唯一标识用户的字符串.就是这样.

人们意识到了这一点，并开发了一种用于创建令牌的新标准，称为 JSON Web Token 标准.该标准基本上提供了一组规则，用于以非常特定的方式创建令牌，这使得令牌对您更有用.

JWT 可让您执行以下操作:

• 对令牌进行加密签名，以便您知道令牌没有被用户篡改.
• 加密令牌，使内容无法以纯文本形式读取.
• 以标准方式将 JSON 数据嵌入到令牌字符串中.

现在，在大多数情况下:开发社区中的几乎每个人都同意，如果您使用任何类型的 OAuth，那么您使用的令牌应该是 JSON Web 令牌.

===========

好的！现在我们已经介绍了背景故事，让我来回答您的问题.

您在上面所做的选择是您是否希望启用完整的 OAuth2 规范以进行身份​​验证/授权(这非常复杂)，或者您是否只是想要一些基本的令牌身份验证".

由于 OAuth 协议提供了多种不同的方式来以符合标准的方式进行身份验证，因此它为大多数身份验证系统增加了很多复杂性.

因此，许多框架都提供了 OAuth2 密码授予流程的简化"版本，这本质上是一种简单的方法，其中:

• 用户通过/login 等 URL 将其用户名/密码发送到您的服务器.
• 您的服务器为用户生成 JWT 令牌.
• 您的服务器将该令牌返回给用户.
• 用户将此令牌存储在他们的 cookie、移动设备或可能的 API 服务器中，并在其中使用它来发出请求.

再次重申:上面的流程不符合 OAuth，但它是一个稍微简单的版本，仍然使用令牌.

这里的重点是令牌 (JWT) 通常很有用，不需要与 OAuth 流程配对.

我知道这是一堵文字墙，但希望它能更深入地回答您的问题 =)

I thought that OAuth is basically a token based authentication specification but most of the time frameworks act as if there is a difference between them. For example, as shown in the picture below Jhipster asks whether to use an OAuth based or a token based authentication.

Aren't these the same thing ? What exactly is the difference since both includes tokens in their implementations ?

解决方案

This is a good question -- there is a lot of confusion around tokens and OAuth.

First up, when you mention OAuth, you are likely referring to the OAuth2 standard. This is the latest version of the OAuth protocol, and is what most people are specifically talking about when they say 'OAuth'.

The OAuth protocol supports several different types of authentication and authorization (4 to be precise).

Secondly, the OAuth protocol works by authenticating users via tokens. The idea here is this:

Instead of having your user send their actual credentials to your server on every single request (like they would with Basic Auth, where a user sends their username/password to the server for each request), with OAuth you first exchange your user credentials for a 'token', and then authenticate users based on this 'token'.

The idea of OAuth is that by requiring users to pass their confidential credentials over the network less frequently, less bad things can happen. (This is the idea, anyhow.)

Now, here's where tokens come into play: the OAuth spec is built around the concept of tokens, but DOES NOT SPECIFY WHAT A TOKEN IS.

In the most 'general' sense, a token is just a string that uniquely identifies a user. That's it.

People realized this, and developed a new standard for creating tokens, called the JSON Web Token standard. This standard basically provides a set of rules for creating tokens in a very specific way, which makes tokens more useful for you in general.

JWTs let you do things like:

• Cryptographically sign a token so you know that a token wasn't tampered with by a user.
• Encrypt tokens so the contents cannot be read in plain text.
• Embed JSON data INSIDE of a token string in a standard way.

Now, for the most part: pretty much everyone in the development community has agreed that if you're using any sort of OAuth, then the tokens you're using should be JSON Web Tokens.

==========

OK! Now that we've covered the backstory, let me answer your question.

The choice you're making above is whether or not you want to enable the full OAuth2 specification for authentication / authorization (which is quite complex), or whether you simply want some basic 'token authentication'.

Because the OAuth protocol provides multiple different ways to authenticate in a STANDARDS COMPLIANT way, it adds a lot of complexity to most authentication systems.

Because of this, a lot of frameworks offer a 'dumbed down' version of the OAuth2 Password Grant flow, which essentially is a simple method where:

• A user sends their username/password to your server at some URL like /login.
• Your server generates a JWT token for the user.
• Your server returns that token to the user.
• The user stores this token in their cookies, mobile device, or possible API server, where they use it to make requests.

Again: the flow above is NOT OAuth compliant, but is a slightly simpler version that STILL uses tokens.

The main point here is that tokens (JWTs) are generally useful, and don't NEED to be paired with the OAuth flow.

I realize this is a wall of text, but hopefully it answers your question in more depth =)

这篇关于基于 OAuth 和基于 Token 的身份验证有什么区别?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！