Защита потенциального спуфинга данных Google OpenID до запрашивающего сайта

Question

Возможно, что у меня что-то действительно глупое, и я пропустил его в документации Google Federated Login, но как логически зарегистрирован аккаунт Google OpenID для запрашивающего сайта? Как запрашивающий сайт знает, что подробности поступают от Google, а не только кто-то вводит параметры строки запроса в URL?

Чтобы проиллюстрировать, я реализую базовую логическую последовательность OpenID в PHP, и все, что кажется возвращенным, представляет собой набор параметров строки запроса в URL-адресе, который я могу использовать для получения данных OpenID, что отлично работает. Проблема в том, что если я просто ввел их в адресную строку вручную без фактического входа в Google, как бы мой запрашивающий сайт знал разницу?

Во-первых, форма запроса детали:

<form method='post' action='https://www.google.com/accounts/o8/ud'> 

    <input type='hidden' name='openid.return_to' value='http://www.example/com/logged-in' /> 

    <input type='hidden' name='openid.mode' value='checkid_setup' /> 
    <input type='hidden' name='openid.ns' value='http://specs.openid.net/auth/2.0' /> 
    <input type='hidden' name='openid.claimed_id' value='http://specs.openid.net/auth/2.0/identifier_select' /> 
    <input type='hidden' name='openid.identity' value='http://specs.openid.net/auth/2.0/identifier_select' /> 

    <input type='hidden' name='openid.ns.ax' value='http://openid.net/srv/ax/1.0' /> 
    <input type='hidden' name='openid.ax.mode' value='fetch_request' /> 
    <input type='hidden' name='openid.ax.required' value='email,firstname,lastname' /> 
    <input type='hidden' name='openid.ax.type.email' value='http://axschema.org/contact/email' /> 
    <input type='hidden' name='openid.ax.type.firstname' value='http://axschema.org/namePerson/first' /> 
    <input type='hidden' name='openid.ax.type.lastname' value='http://axschema.org/namePerson/last' /> 

    <input type='submit' value='Login With Google Account' /> 

</form> 

... который прекрасно работает, посылая меня обратно на запрашиваемый сайт в http://www.example.com/logged-in с целой кучей параметров URL, показанном ниже (от PHP print_r звоните):

Array 
(
    [openid_ns] => http://specs.openid.net/auth/2.0 
    [openid_mode] => id_res 
    [openid_return_to] => http://www.example.com/logged-in 
    [openid_ext1_type_firstname] => http://axschema.org/namePerson/first 
    [openid_ext1_value_firstname] => {user's first name} 
    [openid_ext1_type_email] => http://axschema.org/contact/email 
    [openid_ext1_value_email] => {user's e-mail address} 
    [openid_ext1_type_lastname] => http://axschema.org/namePerson/last 
    [openid_ext1_value_lastname] => {user's last name} 
) 

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

Спасибо за любую помощь, извините, если это уже было задано (не удалось найти какие-либо реплики!), И если я упустил что-то очевидное!

Answer 1

Не вдаваясь в слишком много деталей (прочитайте спецификацию OpenID, если вам нужны детали gory), для протокола OpenID предусмотрены меры предосторожности. Утверждения, которые вы получаете назад, подписаны и поддаются проверке, и существуют ограничения в отношении того, как идентификаторы являются именами, чтобы помешать провайдерам подделывать идентификаторы друг друга. Если вы используете установленную библиотеку (например, php-openid в порядке), вам не придется слишком беспокоиться об этом, так как обычно это берется под обложками. Если вы пытаетесь внедрить свою собственную реализацию ... ну, просто не ...

Сказали, что есть некоторые вещи, которые не являются в протоколе. Например, хотя атрибуты подписаны в ответе, вы не можете предположить, что они точны, если вы не доверяете конкретному провайдеру. В некоторых приложениях будет проверяться URL/имя хоста поставщика, который сделал это утверждение (после проверки ответа) и список белых поставщиков идентификаторов, которые выполняют правильную проверку электронной почты. Если вам требуется подтвержденное электронное письмо, это делает лучший UX. Но если утверждение от неизвестного поставщика удостоверений не предполагает, что адрес электронной почты фактически принадлежит пользователю, если вы не проверите владение собой.