Почему перенаправление HTML-формы используется в OpenID 2?

Почему вы делаете автоматическую запись HTML, а не просто перенаправляете?

Разве это так, что разработчики могут автоматически генерировать форму входа, которая отправляет каталог на удаленный сервер, когда известен OpenID?

например.

  • Пользователь не вошел в систему и не посетил вашу страницу входа.
  • Вы обнаруживаете пользовательский идентификатор openID из файла cookie.
  • Создается форма, которая напрямую отправляется на удаленный сервер OpenID.
  • Удаленный сервер перенаправляет пользователя на веб-сайт.
  • Веб-сайт регистрируется пользователем.

Если это так, я вижу это преимущество. Однако это предполагает, что вы оставляете пользователя openID в файле cookie при выходе из системы.

Я могу найти очень мало информации о том, как лучше всего реализовать эту спецификацию.

См. переформатирование HTML FORM в официальных спецификациях:

http://openid.net/specs/openid-authentication-2_0.html#indirect_comm

Я нашел это из рассмотрения PHP OpenID Library (версия 2.1.1).

// Redirect the user to the OpenID server for authentication.
// Store the token for this authentication so we can verify the
// response.

// For OpenID 1, send a redirect.  For OpenID 2, use a Javascript
// form to send a POST request to the server.
if ($auth_request->shouldSendRedirect()) {
    $redirect_url = $auth_request->redirectURL(getTrustRoot(),
                                               getReturnTo());

    // If the redirect URL can't be built, display an error
    // message.
    if (Auth_OpenID::isFailure($redirect_url)) {
        displayError("Could not redirect to server: " . $redirect_url->message);
    } else {
        // Send redirect.
        header("Location: ".$redirect_url);
    }
} else {
    // Generate form markup and render it.
    $form_id = 'openid_message';
    $form_html = $auth_request->htmlMarkup(getTrustRoot(), getReturnTo(),
                                           false, array('id' => $form_id));

    // Display an error if the form markup couldn't be generated;
    // otherwise, render the HTML.
    if (Auth_OpenID::isFailure($form_html)) {
        displayError("Could not redirect to server: " . $form_html->message);
    } else {
        print $form_html;
    }
}

ОТВЕТЫ

Ответ 1

Основная мотивация заключалась в том, что, как говорит Марк Брэкетт, ограничения на размер полезной нагрузки, налагаемые с помощью перенаправления и GET. Некоторые реализации достаточно умен, чтобы использовать POST только тогда, когда сообщение переходит на определенный размер, поскольку, безусловно, есть недостатки в методе POST. (Главным из них является тот факт, что кнопка "Назад" не работает.) Другие реализации, такие как приведенный вами пример кода, идут для простоты и согласованности и не учитывают этого условного.

Ответ 2

Я могу подумать о нескольких причинах:

  • Мощный уровень безопасности по неизвестности - он немного больше работает, чтобы вмешиваться в сообщения POST, чем GET
  • Правила кэширования и повторной отправки более строгие для POST, чем GET. Я не совсем уверен, что это важно для варианта использования OpenID.
  • Боты не будут следовать форме POST, но последуют за перенаправлением. Это может повлиять на загрузку сервера.
  • Различные браузеры имеют разные максимальные длины для запросов GET, но ни один из них не имеет значения POST.
  • Некоторые браузеры будут предупреждать о переадресации в другой домен. Они также предупреждают, что вы отправляете POST на URL-адрес, отличный от HTTPS.
  • Отключив JavaScript, я могу иметь относительно безопасный опыт и не перенаправлять его в другой домен.

Я не знаю, что любой из них является причиной отказа от POST - если количество отправляемых данных не превышает длину запроса для какого-то крупного браузера.

Ответ 3

Такой же подход используется для профиля SSO веб-браузера SAML. Основные мотивы использования перенаправления HTML Post:

  • Практически неограниченная длина полезной нагрузки: в SAML полезная нагрузка представляет собой документ XML, подписанный с кодировкой XMLDSig и base64. Это больше, чем обычные ограничения на 1024 символа URL (лучшая практика для поддержки не только любых браузеров, но и промежуточных сетевых устройств, таких как Firewall, Reverse Proxy, Load Balancer).

  • В стандарте HTTP W3C говорится, что GET является идемпотентным (один и тот же URL-адрес GET, выполняемый несколько раз, всегда должен приводить к одному и тому же ответу) и, следовательно, может кэшироваться по пути, в то время как POST не является и должен достигать целевой URL. Ответ на OpenID HTML-форму POST или SAML HTML-форму POST не следует кэшировать. Он должен достигнуть цели, чтобы инициировать аутентифицированный сеанс.

Вы можете утверждать, что использование перенаправления HTTP GET также будет работать, поскольку запрос URL всегда изменяется, и вы правы, это практика. Однако это будет обходным путем стандарта W3C и, следовательно, не должно быть стандартной, а альтернативной реализацией всякий раз, когда оба конца согласятся с ней.