Как безопасно выполнять междоменную аутентификацию?

Question

So. У меня есть домен A.com, аутентификация которого выполняется в домене B.com. В настоящее время я устанавливаю его так, чтобы форма входа была отправлена ​​на сайт B.com, который (если succesfull) устанавливает cookie сеанса и запускает перенаправление на A.com/loggedin. Однако, поскольку форма отправляется на B.com, и cookie настроен на этот домен, когда я делаю запрос JSON от A.com, cookie сеанса недоступен, я понятия не имею, вошли ли они в систему или нет. Тогда возникает вопрос, как решить проблему?

Я обдумывал решение, в котором я бы добавил токен к urid перенаправления, который затем можно было использовать для одноразового сеанса с A.com (браузер мог использовать этот токен для авторизации сеанса с B.com, так что cookie будет установлен на A.com и будет доступен по запросам JSON, после чего токен будет недействительным ofc).

Однако я не уверен, насколько безопасно это решение? Или есть другое более безопасное решение?

Answer 1

Ваше текущее решение выглядит хорошо для меня и может быть использовано в этом сценарии. Но для ваших проблем безопасности вместо предоставления простого токена вы можете зашифровать его с помощью некоторого хорошего метода шифрования и на основе этого вы можете настроить серверы для шифрования и дешифрования authentication token перед его использованием. Единственное, что вам нужно выбрать лучший алгоритм для вашего дела.

Кроме этого решения вы можете подумать о средствах управления сеансом. Session Migration, Session Replication и Доступ к сеансу - это варианты, о которых я могу думать.

Здесь Link для решения, предоставляемого Oracle для обмена сеансами, что, я думаю, может помочь в вашем случае.

Answer 2

Использование маркеров аутентификации должны работать нормально, но учтите следующие моменты:

• Использование сильного PRNG для создания маркеров, и генерировать длинный маркер для предотвращения bruteforcing
• Убедитесь, что подержанный маркером будет мгновенно недействительны, чтобы предотвратить повторные атаки

Эти точки очень важны, на мой взгляд, для предотвращения угона токена аутентификации, повторно использующего его. Также ограничьте время, в течение которого токен действителен (30 секунд должны быть точными), чтобы предотвратить злоупотребление старыми/неиспользуемыми токенами.

Answer 3

Да, есть более безопасные варианты.

Для единого входа есть открытый стандарт под названием OpenID/connect (построенный сверху oAuth2.0) Для совместного использования ресурсов, авторизации и аутентификации существует oAuth.

Следует иметь в виду.

1. Все эти решения - это не что иное, как контролируемые утечки - используйте тщательно.
2. Все эти решения оставляют вас неприемлемыми для XSS, человека в середине и атаки на захват/повтор.
3. Из-за пунктов 1 и 2 важна тщательная реализация.

Использовать работу, уже проделанную сообществом.

OAuth 1.0a (по-прежнему широко распространена в качестве наиболее безопасного рисунка до сих пор) - http://tools.ietf.org/html/rfc5849 OAuth 2 - http://oauth.net/2/ (с использованием OpenId для авторизации, построенной на вершине oauth2)

OAuth 2 не является заменой для OAuth 1а - это совершенно новая (менее безопасная) идея, сильно зависящая от SSL. oAuth1a по-прежнему является наиболее безопасной, но все же только такой же хорошей, как и ваша реализация и понимание потенциальных недостатков.

Вы, вероятно, ищет OpenId соединить идеи - но OAuth информация также полезна ...

SO - starting point of some differences

openID connect (layered on oAuth 2)

oAuth concepts

SO - worth a read

Answer 4

Security Assertion Markup Language (SAML, произносится как " sam-el "[1]) является открытым стандартным форматом данных на основе XML для обмена данными аутентификации и авторизации между сторонами, в частности между поставщиком идентификации и поставщиком услуг. SAML является продуктом Технического комитета служб безопасности OASIS. SAML датируется 2001 годом; последнее обновление SAML происходит с 2005 года.

Единственное наиболее важное требование, что SAML-адреса - это однократный вход в систему веб-браузера. Единые входные решения распространены на уровне интрасети (например, с использованием файлов cookie), но расширение этих решений за пределами интрасети было проблематичным и привело к распространению несовместимых проприетарных технологий. (Еще один более поздний подход к решению проблемы SSO для браузера - это протокол OpenID.) Спецификация SAML определяет три роли: главный (обычно пользователь), поставщик удостоверений (IdP) и поставщик услуг (SP). В случае использования, адресованном SAML, основной запрашивает услугу у поставщика услуг. Поставщик услуг запрашивает и получает подтверждение идентификации от поставщика удостоверений. Исходя из этого утверждения, поставщик услуг может принять решение о контроле доступа - другими словами, он может решить, выполнять ли какую-либо услугу для подключенного принципала.

Перед тем как доставить подтверждение идентификации в СП, IdP может запросить некоторую информацию от принципала - например, имя пользователя и пароль - для аутентификации принципала. SAML определяет утверждения между тремя сторонами: в частности, сообщения, которые утверждают идентичность, которые передаются из IdP в SP. В SAML один поставщик удостоверений может предоставлять утверждения SAML для многих поставщиков услуг. И наоборот, один SP может опираться и доверять утверждениям из многих независимых IdP. SAML не указывает метод аутентификации в поставщике удостоверений; он может использовать имя пользователя и пароль или другую форму аутентификации, включая многофакторную аутентификацию. Служба каталогов, которая позволяет пользователям входить в систему с именем пользователя и паролем, является типичным источником токенов аутентификации (например, паролей) у поставщика удостоверений. Популярные общедоступные интернет-сервисы социальных сетей также предоставляют услуги идентификации, которые теоретически могут использоваться для поддержки обменов SAML.

http://en.wikipedia.org/wiki/Security_Assertion_Markup_Language