Step 3: Request User Authentication

Depending on the version of OpenID being used (OpenID version 1 or 2), the request for user authentication will take one of two courses from a programmatic perspective. The code will either:

  • Redirect the user to the endpoint established in the previous step (OpenID v1)

or:

  • Obtain the authentication form markup from the provider endpoint and print it out to the screen for the user (OpenID v2)

In both cases, the process that occurs between the relaying party and the user looks the same, as shown in Figure 11-3.

OpenID, step 3: Provider requests user authentication

Figure 11-3. OpenID, step 3: Provider requests user authentication

In general terms, the relaying party will display the authentication form to the user to have him authenticate herself against the OpenID provider (through either the form or redirect method).

When the relaying party establishes the request between the user and provider for authentication, the request will include a number of OpenID parameters, including those listed in Table 11-1.

Table 11-1. Authentication request parameters

Request parameter

Description

openid.ns

The OpenID namespace URI to be used. For instance, this should be http://specs.openid.net/auth/2.0 for OpenID 2.0 transactions.

openid.mode

The transaction mode to be used during the authentication process. The possible values are checkid_immediate or checkid_setup.

If the user should be able to interact with the OpenID provider, then checkid_setup should be used.

openid.claimed_id (optional)

The claimed OpenID identifier, provided by the user.

openid.identity (optional)

The local OpenID provider identifier. If http://specs.openid.net/auth/2.0/identifier_select is used as the identity, then the provider should choose the correct identifier for the user.

openid.assoc_handle (optional)

A handle for an association between the relaying party (implementing site) and the OpenID provider that should be used to sign the request.

openid.return_to (optional)

The location where the user should be returned, with the OpenID response, after authentication has taken place.

Many web-based providers require this field. If it is not included, it indicates that the relaying party does not want to return the user after authentication.

openid.realm (optional)

The URL pattern for the domain that the user should trust. For instance, *.mysite.com.

Note, if openid.return_to is omitted from the request, openid.realm is a required parameter.

The user, once presented with the form, will either authenticate or not. In either case, the user’s response will be returned to the relaying party. This response object that is returned will include the parameters listed in Table 11-2.

Table 11-2. Authentication response parameters

Response parameter

Description

openid.ns

The OpenID namespace URI.

openid.mode

The current authentication mode. This value will be id_res at this point.

openid.op_endpoint

The endpoint URI of the OpenID provider to which the user was sent.

openid.claimed_id (optional)

The claimed OpenID identification URI for the user on the provider site.

In the response object, openid.claimed_id and openid.identity will either both be present or absent.

openid.identity (optional)

The local identifier for the user on the provider site. For some providers, this value will usually be identical to the openid.claimed_id parameter.

openid.return_to

An exact copy of the return_to parameter provided in the original user authentication request.

openid.response_nonce

A unique string of 255 characters or fewer. The nonce will start with the current server time.

openid.invalidate_handle (optional)

This will include an invalidation handle from the server if one was produced.

openid.assoc_handle

The handle for the association that was used to sign this assertion.

openid.signed

A comma-separated list of the fields that were signed with the request. This list must contain at least op_endpoint, return_to, response_nonce, assoc_handle, and, if present in the response, claimed_id and identity.

openid.sig

The base 64–encoded signature.

The relaying party and OpenID provider will then communicate with each other to complete the authentication process and provide the appropriate approval state.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.144.90.182