Які основні відмінності між автентифікацією 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 проти маркерів: Постійний посібник ) може бути корисною прочитаною з цього приводу, особливо розділом захисту 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 (Simple Web Token).

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

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

Захист CSRF - Вам не потрібно застосовувати захист CSRF, якщо ви не зберігаєте маркер у файлі cookie браузера.

Більш детальну інформацію ви можете прочитати тут http://proficientblog.com/microservices-security/

Схоже, що всі, хто відповів тут, пропустили суперечливість OAUTH

З Вікіпедії

OAuth - це відкритий стандарт для делегування доступу, який зазвичай використовується як спосіб, щоб користувачі Інтернету надавали веб-сайтам чи програмам доступ до їх інформації на інших веб-сайтах, але без надання їм паролів. [1] Цей механізм використовується такими компаніями, як Google, Facebook, Microsoft та Twitter, щоб дозволити користувачам обмінюватися інформацією про свої облікові записи із сторонніми додатками чи веб-сайтами.

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

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

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

Ще одна важлива примітка:
Ви вільно використовуєте слово authenticationдля JWT та OAUTH, але не надаєте механізму аутентифікації. Так, один є механізмом лексем, а другий - протоколом, але після автентифікації вони використовуються лише для авторизації (управління доступом). Ви можете створити резервну копію OAUTH або за допомогою аутентифікації типу OPENID, або власних облікових даних клієнта

знайти основні відмінності між JWT та OAuth

1. OAuth 2.0 визначає протокол, а JWT визначає формат маркера.

2. OAuth може використовувати або JWT у вигляді формату лексеми, або маркер доступу, який є маркером носія.

3. OpenID-з'єднання здебільшого використовують JWT як формат маркера.

JWT - це відкритий стандарт, який визначає компактний та автономний спосіб безпечної передачі інформації між сторонами. Це протокол аутентифікації, де ми дозволяємо кодовані претензії (жетони) передаватись між двома сторонами (клієнтом і сервером), а маркер видається після ідентифікації клієнта. З кожним наступним запитом ми надсилаємо маркер.

Тоді як OAuth2 - це структура авторизації, де вона має загальні процедури та установки, визначені рамкою. JWT може використовуватися як механізм всередині OAuth2.

Більше про це можна прочитати тут

OAuth чи JWT? Який з них використовувати і навіщо?

Питання є поширеним, але не зовсім розумним. JWT - це тип жетонів, а OAuth - це Рамка, яка описує, як видавати жетони.

Що ми маємо на увазі під «рамкою»? Просто послідовність запитів і відповідей, а також формати тих, які можна і потрібно використовувати для запиту жетонів. OAuthv2 описує окремі "потоки" або типи грантів для різних сценаріїв і має різні розширення (наприклад, PKCE) для розширення безпеки певних потоків.

Результатом запиту-токена через грант OAuthV2 є ... маркер. Тоді ця річ використовується як "маркер носія", що означає, що будь-яка сторона, яка має маркер, може представити її під час запиту 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 підтримує "Federation" - кожен може генерувати маркер, і будь-хто може прочитати та перевірити маркер.

власні претензії. Як JWT, так і непрозорі маркери OAuth можуть пред’являти власні претензії щодо цього питання. безпека. Обидва - це жетони носія. Обох потрібно берегти як таємниці. термін придатності. Обидва можуть бути позначені терміном закінчення. Обидва можна оновити. Механізм або досвід аутентифікації. Обидва можуть представляти однаковий досвід користувачів.

Jwt - це суворий набір інструкцій щодо видачі та підтвердження підписаних жетонів доступу. Маркери містять претензії, які використовує додаток для обмеження доступу до користувача

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

Примітка. Oauth2 може працювати з jwt, гнучкою реалізацією, доступною для різних програм