Единого входа потока с использованием проверки подлинности для проверки подлинности домена крест

существует много информации в интернете об использовании JWT (Json Web Token) для проверки подлинности. Но я все еще не нашел четкого объяснения того, каким должен быть поток при использовании токенов JWT для решение для единого входа в среде с несколькими доменами.

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

С помощью OpenId Connect поток, я понимаю, что пользователь, который хочет пройти аутентификацию на example1.com сначала будет перенаправлен на проверка подлинности сервера (или OP : "OpenId Provider"). Пользователь авторизируется на сервере, который затем перенаправляет его обратно к оригиналу 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?

мы не хотим ничего особенного, мы были бы счастливы с главным образом используемым решением!

3 61
forms-authentication jwt single-sign-on openid-connect

3 ответа:

пользователь должен быть перенаправлен на сервер аутентификации снова и получить новый токен (JWT), который специально предназначен для example2.com именно так работает OpenID Connect и любой другой междоменный федеративный протокол SSO.

15

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

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

example2.com не может получить доступ к данным из example1.com но есть технология для обмена данными между доменами с помощью браузера localStorage / cookies и iframe, указывающего на промежуточный домен sso.example.com

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

  2. создать iframe в example2.com указывая на sso.example.com. Iframe внутри sso.example.com считывает токен JWT и отправляет сообщение на родительскую страницу

  3. родительская страница получает сообщение и получает прикрепленный маркер, продолжая поток SSO

нет никаких проблем с политикой того же происхождения, потому что sso.example.com имеет доступ к своему localStorage и связь между iframe и родительской страницей разрешена, если источник и назначение распознают друг друга (см. http://blog.teamtreehouse.com/cross-domain-messaging-with-postmessage)

чтобы упростить разработку, мы недавно выпустили кросс домен SSO с JWT в https://github.com/Aralink/ssojwt

этот метод идеально совместим с потоками SSO. Это просто способ поделиться проверки подлинности на основе маркеров без перенаправления и избежать ненужных входов в систему, когда Домены объединены

14

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

Так example1.com example2.com

станет чем-то вроде

example.com/example1

example.com/example2

(и со стороны пользователя, это обычно чище)

Если это не вариант, возможно, вам придется настроено так, что когда пользователь аутентифицируется в 1 домене, он использует AJAX/hidden iframes для создания аутентификации с другими доменами (отправка маркера 1 раз через url, если необходимо).

и если это не вариант, вам, возможно, придется прибегнуть к username+pin, так как браузеры становятся все более строгими в отношении междоменного взаимодействия.

1