Каковы основные различия между аутентификацией JWT и OAuth?

У меня есть новый SPA с безстоящей аутентификационной моделью с использованием JWT. Меня часто просят передать OAuth для потоков аутентификации, например, просить меня отправлять "токены носителей" для каждого запроса вместо простого заголовка токена, но я думаю, что OAuth намного сложнее простой проверки подлинности на основе JWT. В чем главные отличия, следует ли заставить JWT-аутентификацию вести себя как OAuth?

Я также использую JWT как мой XSRF-TOKEN для предотвращения XSRF, но меня просят сохранить их отдельно? Должен ли я держать их отдельно? Любая помощь здесь будет оценена и может привести к набору руководящих принципов для сообщества.

Ответ 1

TL; DR Если у вас очень простые сценарии, такие как одно клиентское приложение, один API, то, возможно, не будет оправдано использование OAuth 2.0, с другой стороны, множество разных клиентов (на основе браузера, встроенный мобильный, серверный и т.д.) тогда соблюдение правил OAuth 2.0 может сделать его более управляемым, чем пытаться развернуть собственную систему.

Как указано в другом ответе, JWT (Learn JSON Web Tokens) - это просто формат токенов, он определяет компактный и автономный механизм для передачи данных между сторонами таким образом, чтобы его можно было проверять и доверять, поскольку он имеет цифровую подпись. Кроме того, правила кодирования JWT также делают эти маркеры очень простыми в использовании в контексте HTTP.

Будучи самодостаточными (фактический токен содержит информацию о заданном субъекте), они также являются хорошим выбором для реализации механизмов аутентификации без сохранения состояния (иначе, смотрите, мама, никаких сеансов!). При прохождении этого маршрута и единственной вещи, которую должна предоставить сторона, чтобы получить доступ к защищенному ресурсу, является сам токен, этот токен можно назвать токеном-носителем.

На практике то, что вы делаете, уже может быть классифицировано как основанное на жетонах на предъявителя. Однако учтите, что вы не используете токены на предъявителя, как указано в спецификациях, связанных с OAuth 2.0 (см. RFC 6750). Это подразумевает использование HTTP-заголовка Authorization и использование схемы аутентификации Bearer.

Что касается использования JWT для предотвращения CSRF, не зная точных деталей, трудно установить обоснованность этой практики, но, честно говоря, это не кажется правильным и/или стоящим. Следующая статья (Cookies vs Tokens: The Definitive Guide) может быть полезна для чтения на эту тему, особенно в разделе Защита XSS и XSRF.

И последний совет: даже если вам не нужен полный OAuth 2.0, я настоятельно рекомендую передавать ваш токен доступа в заголовок Authorization вместо использования пользовательских заголовков. Если они действительно являются токенами на предъявителя, следуют правилам RFC 6750, в противном случае вы всегда можете создать собственную схему аутентификации и по-прежнему использовать этот заголовок.

Заголовки авторизации распознаются и обрабатываются HTTP-прокси и серверами. Таким образом, использование таких заголовков для отправки маркеров доступа на серверы ресурсов снижает вероятность утечки или непреднамеренного хранения аутентифицированных запросов в целом, и особенно заголовков авторизации.

(источник: RFC 6819, раздел 5.4.1)

Ответ 2

OAuth 2.0 определяет протокол, то есть указывает, как переносятся токены, JWT определяет формат токена.

OAuth 2.0 и "JWT-аутентификация" имеют схожий внешний вид, когда речь идет о (2-м) этапе, когда Клиент представляет токен серверу ресурсов: токен передается в заголовке.

Но "аутентификация JWT" не является стандартом и не указывает, как клиент получает маркер в первую очередь (1-й этап). Именно здесь происходит осознанная сложность OAuth: она также определяет различные способы, которыми Клиент может получить токен доступа от того, что называется сервером авторизации.

Таким образом, реальная разница заключается в том, что JWT - это просто формат токена, OAuth 2.0 - это протокол (который может использовать JWT как формат токена).

Ответ 3

Во-первых, мы должны различать JWT и OAuth. В принципе, JWT является форматом токена. OAuth - это протокол авторизации, который может использовать JWT в качестве токена. OAuth использует серверную и клиентскую память. Если вы хотите выполнить реальный выход из системы, вы должны пойти с OAuth2. Аутентификация с помощью токена JWT не может выйти из системы на самом деле. Поскольку у вас нет сервера аутентификации, который отслеживает токены. Если вы хотите предоставить API сторонним клиентам, вы также должны использовать OAuth2. OAuth2 очень гибкий. Реализация JWT очень проста и не требует много времени для реализации. Если вашему приложению нужна такая гибкость, вы должны пойти с OAuth2. Но если вам не нужен этот сценарий использования, реализация OAuth2 - пустая трата времени.

Маркер XSRF всегда отправляется клиенту в каждом заголовке ответа. Не имеет значения, отправлен ли токен CSRF в токере JWT или нет, поскольку токен CSRF защищен сам собой. Поэтому отправка токена CSRF в JWT не требуется.

Ответ 4

JWT (JSON Web Tokens) - это просто формат токена. Точки JWT представляют собой структуры данных, закодированные JSON, содержат информацию об эмитенте, субъекте (претензиях), времени истечения и т.д. Он подписан для подтверждения и аутентификации и может быть зашифрован для защиты информации маркера с использованием симметричного или асимметричного подхода. JWT проще, чем SAML 1.1/2.0 и поддерживается всеми устройствами, и он более мощный, чем SWT (простой веб-токен).

OAuth2 - OAuth2 решает проблему, с которой пользователь хочет получить доступ к данным с помощью клиентского программного обеспечения, такого как веб-приложения на основе просмотра, собственные мобильные приложения или настольные приложения. OAuth2 предназначен только для авторизации, клиентское программное обеспечение может иметь право доступа к ресурсам от имени конечного пользователя с использованием токена доступа.

OpenID Connect - OpenID Connect строит поверх OAuth2 и добавляет аутентификацию. OpenID Connect добавляет некоторое ограничение на OAuth2, например, конечную точку UserInfo, идентификатор ID, обнаружение и динамическую регистрацию поставщиков OpenID Connect и управление сеансом. JWT - обязательный формат для токена.

Защита CSRF. Вам не нужно реализовывать защиту CSRF, если вы не храните токен в cookie браузера.

Вы можете прочитать более подробную информацию здесь http://proficientblog.com/microservices-security/

Ответ 5

Похоже, что все, кто здесь ответил, пропустили спорную точку OAUTH

Материал из Википедии

OAuth - это открытый стандарт для делегирования доступа, обычно используемый как способ для пользователей Интернета предоставлять веб-сайтам или приложениям доступ к их информации на других сайтах, но не давая им пароли. [1] Этот механизм используется такими компаниями, как Google, Facebook, Microsoft и Twitter, чтобы пользователи могли обмениваться информацией об их аккаунтах с сторонними приложениями или веб-сайтами.

Ключевым моментом здесь является access delegation. Зачем кому-то создавать OAUTH, когда существует аутентификация на основе id/pwd, поддерживаемая многофакторными auth, такими как OTP, и далее может быть защищена JWT, которые используются для защиты доступа к путям (например, области OAUTH) и установить истечение срока действия доступ

Нет смысла использовать OAUTH, если пользователи получат доступ к своим ресурсам (вашим конечным точкам) только через свои надежные веб-сайты (или приложения), которые вы снова размещаете в своих конечных точках.

Вы можете использовать только аутентификацию OAUTH , если вы OAUTH provider в тех случаях, когда владельцы ресурсов (пользователи) хотят получить доступ к своим (вашим) ресурсам (конечным точкам) через сторонний клиент (внешний app). И это точно создано с той же целью, хотя вы можете злоупотреблять им вообще

Еще одно важное замечание:
Вы свободно используете слово authentication для JWT и OAUTH, но не предоставляете механизм аутентификации. Да, это механизм токена, а другой - протокол, но после аутентификации они используются только для авторизации (управления доступом). Вы должны вернуть OAUTH либо с аутентификацией типа OPENID, либо с вашими собственными учетными данными клиента

Ответ 6

JWT - это открытый стандарт, который определяет компактный и автономный способ безопасной передачи информации между сторонами. Это протокол аутентификации, в котором мы разрешаем передачу закодированных заявок (токенов) между двумя сторонами (клиентом и сервером), и токен выдается при идентификации клиента. С каждым последующим запросом мы отправляем токен.

Принимая во внимание, что OAuth2 является структурой авторизации, где он имеет общие процедуры и установки, определенные платформой. JWT может использоваться как механизм внутри OAuth2.

Вы можете прочитать больше об этом здесь

OAuth или JWT? Какой использовать и почему?

Ответ 7

найти основные различия между JWT и OAuth

OAuth 2.0 определяет протокол, а JWT определяет формат токена.
OAuth может использовать либо JWT в качестве формата токена, либо токен доступа, который является токеном-носителем.
OpenID connect в основном использует JWT в качестве формата токена.

Ответ 8

Jwt - это строгий набор инструкций для выдачи и проверки подписанных токенов доступа. В токенах содержатся утверждения, которые используются приложением для ограничения доступа к пользователю

OAuth2, с другой стороны, не является протоколом, его делегированной структурой полномочий. подумайте о очень подробном руководстве, чтобы позволить пользователям и приложениям разрешать определенные разрешения другим приложениям как в частных, так и в общественных настройках. OpenID Connect, который находится поверх OAUTH2, дает вам Authentication and Authorization.it подробную информацию о том, как несколько разных ролей, пользователей в вашей системе, приложения на стороне сервера, такие как API, и клиенты, такие как веб-сайты или мобильные приложения, могут аутентифицироваться с каждой

Примечание. Oauth2 может работать с jwt, гибкая реализация, расширяемая для разных приложений