Один потік входу за допомогою JWT для міждоменної аутентифікації

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

Я працюю в компанії, яка має багато сайтів у різних хостів. Давайте скористаємося example1.com та example2.com . Нам потрібно єдине рішення для входу, що означає, що якщо користувач перевіряє автентифікацію на example1.com , ми хочемо, щоб він також був автентифікований на example2.com автоматично.

Використовуючи потік OpenId Connect , я розумію, що користувач, який хоче пройти автентифікацію на example1.com , спочатку буде переспрямований на сервер аутентифікації (або OP: "Провайдер OpenId"). Користувач аутентифікується на цьому сервері, який потім перенаправляє його назад на оригінальний сайт example1.com з підписаним маркером JWT. (Я розумію, є ще один потік, який повертає проміжний маркер, який згодом можна обміняти на справжній маркер JWT, але я не думаю, що це потрібно для нас) ...

Отже, тепер користувач повернувся на сторінку example1.com і має автентифікацію! Він може робити запити, передаючи маркер JWT у Authenticationзаголовок, і сервер може перевірити підписаний JWT і, таким чином, може ідентифікувати користувача. Приємно!

Перше питання:

Як маркер JWT повинен зберігатися на клієнті? Знову, про це багато інформації, і люди, схоже, згодні, що використання Web Storage- це шлях, а не добрий старий cookies. Ми хочемо, щоб JWT був стійким між перезавантаженнями браузера, тому давайте використовувати Local Storage, а не Session Storage...

Тепер користувач може перезапустити свій веб-переглядач, і він все ще буде автентифікований на example1.com , доки термін JWT не закінчився!

Крім того, якщо example1.com потребує запиту Ajax до іншого нашого домену, я розумію, що налаштування CORS це дозволить. Але основним нашим випадком використання є не міждоменні запити, це єдине рішення для входу !

Тому головне питання:

Тепер, яким повинен бути потік, якщо користувач переходить на example2.com і ми хочемо, щоб він був аутентифікований, використовуючи маркер JWT, який у нього вже є? Local StorageСхоже, не дозволяє міждоменний доступ, тому в цей момент браузер не може прочитати токен JWT для запитів на example2.com !

Потрібно:

• Користувача знову буде переспрямовано на сервер аутентифікації ? Коли користувач пройшов автентифікацію для example1.com , сервер автентифікації, можливо, встановив на нього cookie, щоб цей новий запит на аутентифікацію для example2.com міг використати цей файл cookie, щоб побачити, що користувач вже автентифікований, і негайно перенаправляє його назад на example2.com з тим же маркером JWT?
• Чи може браузер на example2.com отримати доступ до токена JWT без необхідності повторного переходу на сервер аутентифікації ? Я бачу, що є рішення для зберігання даних , але чи широко застосовуються такі? Чи запропоновано вони рішення для міждоменного середовища SSO?

Ми не хочемо нічого фантазійного, ми були б задоволені в основному використовуваним рішенням!

Користувача слід знову переспрямувати на сервер аутентифікації та отримати новий маркер (JWT), той, який спеціально орієнтований на example2.com. Так працює OpenID Connect та будь-який інший протокол SSO, що об'єднаний між доменами.

Перенаправлення користувача на центральну службу аутентифікації, коли користувач не входить у систему, щоб запитувати облікові дані та видавати новий маркер аутентифікації, є загальним сценарієм у системах єдиного входу, використовуючи відомі протоколи, наприклад oauth2 або OpenId Connect

Однак, коли ця схема використовується в усіх доменах, головним недоліком є ​​те, що користувач буде перенаправлений та автентифікований кожен раз, коли він переходить на інший домен через політику того самого походження : маркер доступу не може бути спільним між доменами ( example2.comне може отримати доступ до даних of example1.com), тож цільовий домен розглядає користувача як неаутентифікований, перенаправляючи його до центральної служби SSO.

Щоб служба автентифікації не вимагала повторного запиту облікових даних, звичайно мати файли cookie сеансу (а не маркер доступу), але існує техніка для обміну даними між доменами за допомогою браузера localStorage / cookies та iframe, що вказує на проміжний домен sso.example.com

1. Щоб автентифікувати користувача в example1.com, переадресуйте його на сервер аутентифікації sso.example.com, видайте JWT після аутентифікації та зберігайте його в localStorage цього домену. Після цього перенаправляйте користувача на початковий домен example1.com

2. Створіть рамку для example2.comвказівки на sso.example.com. Iframe в sso.example.com зчитує маркер JWT і надсилає повідомлення на батьківську сторінку

3. Батьківська сторінка отримує повідомлення та отримує доданий маркер, продовжуючи потік SSO

Не існує жодної проблеми з політикою з однаковим походженням, оскільки sso.example.comдоступ до її локального сховища та зв’язок між iframe та батьківською сторінкою дозволені, якщо походження та цільові домени розпізнають один одного (див. Http://blog.teamtreehouse.com/cross-domain- обмін повідомленнями після повідомлення )

Для спрощення розробки нещодавно ми випустили крос-домен SSO з JWT за адресою https://github.com/Aralink/ssojwt

Цей метод ідеально сумісний з потоками SSO. Це лише спосіб спільного використання маркера аутентифікації без перенаправлень та уникнення зайвих входів при федерації доменів

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

Так example1.com example2.com

стане чимось подібним

example.com/example1

example.com/example2

(І з боку користувача, це зазвичай чистіше)

Якщо це не варіант, можливо, вам доведеться налаштувати так, що коли користувач перевіряє автентифікацію в 1 домені, він використовує AJAX / приховані iframes для створення автентифікації і з іншими доменами (надсилаючи одноразовий маркер через URL, якщо потрібно ).

і якщо це не варіант, можливо, вам доведеться вдатися до імені користувача + PIN-коду, оскільки браузери стають суворішими щодо взаємодії між доменами.