it-roy-ru.com

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

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

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

190
Tech Junkie

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


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

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

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

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

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

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

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

190
João Angelo

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

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

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

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

159
Hans Z.

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

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

70
Melikşah Şimşek

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, идентификатор токена, обнаружение и динамическая регистрация поставщиков OpenID Connect и управление сеансами. JWT является обязательным форматом для токена.

CSRF защита - вам не нужно реализовывать защиту CSRF, если вы не храните токен в куки-файле браузера.

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

35
ManishSingh

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

Из Википедии

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

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

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

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

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

29
user3151330

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

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

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

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

5
Samuel J Mathew

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

  1. OAuth 2.0 определяет протокол, а JWT определяет формат токена.

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

  3. OpenID connect в основном использует JWT в качестве формата токена.

0
Suraj Kumar Pandey

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

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

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

0
naila naseem