Why is HTML form redirection used in OpenID 2?

Question

Why would you do an automatic HTML post rather than a simple redirect?

Is this so developers can automatically generate a login form that posts directory to the remote server when the OpenID is known?

eg.

1. User is not logged in and visits your login page.
2. You detect the user's openID from a cookie.
3. Form is generated that directly posts to remote OpenID server.
4. Remote server redirects user back to website.
5. Website logs in the user.

If this is the case I can see the benefit. However this assumes that you keep the user's openID in a cookie when they log out.

I can find very little information on how this spec should be best implemented.

See HTML FORM Redirection in the official specs:

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

I found this out from looking at the PHP OpenID Library (version 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;
    }
}

Answer 1

I can think of a couple of reasons:

• A modicum of security by obscurity - it's slightly more work to tamper with POST submissions than GET
• Caching and resubmit rules are more restrictive for POST than GET. I'm not entirely sure this would matter for the OpenID use case, though.
• Bots wouldn't follow the POST form, but would follow the redirect. This could impact server load.
• Different browsers have different max lengths for GET requests - but none of them are as large as POST.
• Some browsers will warn on redirect to another domain. They'll also warn if you're submitting POST to a non-HTTPS url.
• By turning JavaScript off, I can have a relatively secure experience, and not be silently redirected to another domain.

I don't know that any of these are a slam-dunk reason to choose POST - unless the amount of data being sent exceeds the querystring length for some major browser.