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

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

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

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

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

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

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

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

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

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

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

OAuth 2.0 определяет протокол, т. Е. Определяет способ передачи токенов, JWT определяет формат токенов.

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

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

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

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

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

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

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

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

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

Из Википедии

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что мы подразумеваем под «рамками»? Только последовательность запросов и ответов и форматы тех, которые можно и нужно использовать для запроса токенов. OAuthv2 описывает отдельные «потоки» или типы предоставления для разных сценариев и имеет разные расширения (например, PKCE) для повышения безопасности отдельных потоков.

Результатом запроса на токен через грант OAuthV2 является ... токен. Затем эта вещь используется в качестве «токена на предъявителя», что означает, что любая сторона, которая владеет токеном, может представить его при создании запроса API на обслуживание API (например, «каков баланс на моей карте сохраненной стоимости?»). Как токен на предъявителя, он работает как наличные деньги. Если вы держите его, вы можете использовать его. (Хотя в отличие от наличных денег токен - это не «используй и теряй». Может быть, лучшая аналогия - билет на проезд в течение всего дня в системе общественного транспорта или билет на весь день в Disneyworld.)

JWT - это особый тип токена, и JWT может абсолютно использоваться в качестве токена OAuth Bearer. На самом деле это самая распространенная практика. В свете этого «JWT vs OAuth» - это сравнение яблок и яблочных повозок.

Часто люди думают, что «токен OAuth» всегда подразумевает непрозрачный токен - случайную последовательность буквенно-цифровых символов, не содержащую никакого внутреннего значения - который предоставляется диспансером токенов OAuth, который затем может быть проверен только той же самой системой диспетчера OAuth. Но это не единственный вид OAuth-токена. Непрозрачный токен является одним из видов токенов; JWT может использоваться в качестве другого типа токена OAuth.

JWT, напротив, не являются непрозрачными. JWT не является «указателем» или ссылкой на информацию. На самом деле он содержит много конкретной информации, которую может извлечь и интерпретировать любая сторона, имеющая токен. Поскольку JWT содержит реальную информацию, JWT может быть большим; 300 байтов, 500 байтов или более, в зависимости от содержащихся в нем утверждений и алгоритма, использованного для его подписания. Когда люди говорят, что «JWT самоутверждается», что они имеют в виду, любой держатель JWT может открыть его, проверить его, а затем принять решение об авторизации на основе утверждений, представленных в нем. Проверка JWT означает: проверку его структуры, декодирование кодировки base64, проверку правильности ключа, проверку подписи, затем проверку наличия требуемых утверждений в токене, проверку истечения срока действия. Это не простая вещь, скорее, это многошаговый процесс, но, конечно, есть множество библиотек на разных языках программирования, которые поддерживают это, и, конечно, есть политика VerifyJWT, которая помогает вам делать это в прокси API Apigee Edge. Дело в том, что любой владелец или получатель может проверить токен. По этой причине мы говорим, что JWT поддерживает «Федерацию» - любой может сгенерировать токен, а любой может прочитать и проверить токен.

таможенные претензии. И JWT, и непрозрачные OAuth-токены могут нести пользовательские утверждения по этому вопросу. безопасность. Оба являются токенами на предъявителя. Оба должны быть защищены как секреты. истечения срока действия. Оба могут быть отмечены с истечением срока действия. Оба могут быть обновлены. Механизм аутентификации или опыт. Оба могут представлять один и тот же пользовательский опыт.

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

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

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