Похоже, что URL-адреса OpenID, возвращаемые Google, зависят от используемого значения openid.realm. Кроме того, я только что попробовал процесс OpenID с областью, установленной на http://MYREALM и openid.return_to, установленной на http://localhost/openid.php, но получил HTTP 400 Bad Request. По-видимому, Google проверяет, что область имеет тот же домен (и, вероятно, порт), что и URL-адрес возврата.
Одной из идей для обхода проблемы является сохранение адреса Gmail, связанного с OpenID. Всякий раз, когда вы запрашиваете Google OpenID, всегда запрашивайте адрес электронной почты пользователя через тип атрибута Exchange http://axschema.org/contact/email. Если вы когда-либо меняете домены, вы можете связать новый OpenID URL с их учетной записью на основе адреса электронной почты.
Примечание. обязательно необходимо проверить подпись HMAC-SHA1. В противном случае любой пользователь сможет «вернуться» к действию проверки OpenID вашего веб-приложения с созданным адресом электронной почты, что позволит им захватить чей-либо аккаунт, если он знает адрес Gmail получателя.
Когда пользователь впервые после переключения входит в свою учетную запись Google, процедура миграции:
Отправьте запрос POST на https://www.google.com/accounts/o8/ud со следующими параметрами:
+---------------------+----------------------------------+
| openid.ns | http://specs.openid.net/auth/2.0 |
| openid.mode | associate |
| openid.assoc_type | HMAC-SHA1 |
| openid.session_type | no-encryption |
+---------------------+----------------------------------+
(при необходимости заменить openid.realm=http://NEWREALM)
Ответ будет примерно таким:
ns:http://specs.openid.net/auth/2.0
session_type:no-encryption
assoc_type:HMAC-SHA1
assoc_handle:B5hJNa39Cl39BXSOKMqkPpk03rJmE0GI6EhHBkvfLOBFAMMQX67HjuFq
expires_in:46800
mac_key:F5XUXvoYutLvFv4IzJS0diytLmbe
При перенаправлении на служебный URI, https://www.google.com/accounts/o8/ud, режим 'checkid_setup', обязательно отправьте ранее полученный assoc_handle, а также запросите адрес электронной почты пользователя через Attribute Exchange. Другими словами, обязательно отправьте следующие дополнительные параметры:
+----------------------+----------------------------------------------------------+
| openid.assoc_handle | B5hJNa39Cl39BXSOKMqkPpk03rJmE0GI6EhHBkvfLOBFAMMQX67HjuFq |
| openid.ns.ax | http://openid.net/srv/ax/1.0 |
| openid.ax.mode | fetch_request |
| openid.ax.type.email | http://axschema.org/contact/email |
| openid.ax.required | email |
+----------------------+----------------------------------------------------------+
Запрос на возврат будет включать важные параметры openid_signed, openid_sig и openid_ext1_value_email.
- Выполните процедуру спецификации подписи OpenID Authentication 2.0 для генерации подписи . Если base64-кодировка подписи HMAC-SHA1 отличается от значения
openid_sig, тогда подпись недействительна. Обратите внимание, что ключ MAC в этом примере - F5XUXvoYutLvFv4IzJS0diytLmbe. Используйте любой сервер Google, отправленный обратно с запросом на ассоциацию.
На странице документации Google по федеративному входу в систему указано, что http://axschema.org/contact/email "[r] соответствует адресу электронной почты пользователя". Предположительно, после создания учетной записи Google адрес электронной почты "Gmail" будет зафиксирован. Но если это предположение неверно, то использовать эту процедуру небезопасно, поскольку злонамеренный пользователь может изменить свой адрес электронной почты, возвращенный службой федеративного входа, на любой адрес электронной почты учетной записи, которую он хочет украсть.
Чтобы быть в безопасности, перед активацией нового OpenID отправьте запрос подтверждения по электронной почте на адрес электронной почты. Ссылка для проверки будет содержать одноразовый номер, связанный с новым OpenID. После нажатия на ссылку новый OpenID будет полностью связан с учетной записью пользователя, поскольку получение одноразового номера будет проверять связь между адресом электронной почты и новым URL OpenID.
См. Также: openid.sig - Как он генерируется?