Как объединить два разных веб-сайта с общим логином, не раскрывая пароли?
У меня есть веб-сайт, называемый «Site One», на котором пользователи создают учетные записи с именем пользователя и паролем. Затем в целях безопасности я солю и хэширую пароль пользователя и сохраняю его в базе данных SQL. Все отлично работает.
Теперь введите «Второй сайт», который написан другой компанией. Мы хотели бы интегрировать два приложения, чтобы, если пользователь вошел на Сайт 2, он мог:
- Создайте учетную запись на первом сайте через веб-API.
- Получите возможность беспрепятственно войти в систему одним щелчком мыши с сайта два обратно на сайт один.
Возможно ли это, если второй сайт не сможет сохранять и извлекать пароль от созданной ими учетной записи? Единственный способ, которым я могу думать об этой работе, заключается в том, что после того, как второй сайт сделает вызов WebAPI на сайт один для создания учетной записи, второй сайт должен будет иметь возможность хранить пароль, который изначально использовался для создания этой учетной записи, таким образом открытие большой дыры в безопасности на случай, если кто-то сможет получить пароль.
Я предполагал, что в качестве дополнительного уровня безопасности я мог бы предотвратить использование этого пароля, кроме случаев, когда информация для входа публикуется с известного IP-адреса, но я не уверен, что это достаточная защита.
Ответы 1
Рассмотрите возможность внедрения единого входа (SSO) с использованием SAML 2.0, где первый сайт является поставщиком удостоверений (IdP) поставщиком услуг (SP), а второй сайт - поставщиком услуг.
Предполагая, что пользователи сначала посетят второй сайт, тогда вы захотите внедрить систему единого входа, инициированную поставщиком услуг на втором сайте. Эффект от этого будет заключаться в том, что всякий раз, когда пользователь запрашивает защищенный ресурс на Сайте 2, пользователь будет направлен на Сайт Один, который запросит у пользователя имя пользователя и пароль. После аутентификации пользователь будет перенаправлен обратно на второй сайт для доступа к защищенному ресурсу, который изначально запрашивался пользователем.
Обзор взят из Документация OASIS SAML 2.0:
The user attempts to access a resource on sp.example.com. The user does not have a valid logon session (i.e. security context) on this site. The SP saves the requested resource URL in local state information that can be saved across the web SSO exchange.
The SP sends an HTTP redirect response to the browser (HTTP status 302 or 303). The Location HTTP header contains the destination URI of the Sign-On Service at the identity provider.
The Single Sign-On Service determines whether the user has an existing logon security context at the identity provider that meets the default or requested authentication policy requirements. If not, the IdP interacts with the browser to challenge the user to provide valid credentials.
The user provides valid credentials and a local logon security context is created for the user at the IdP.
The IdP Single Sign-On Service builds a SAML assertion representing the user's logon security context. The Single Sign-On Service sends the HTML form back to the browser in the HTTP response.
The browser, due either to a user action or execution of an “auto-submit” script, issues an HTTP POST request to send the form to the SP's Assertion Consumer Service.
An access check is made to establish whether the user has the correct authorization to access the resource. If the access check passes, the resource is then returned to the browser.