Programming Social Applications

Step 3: Request User Authentication Permissions

Once the relaying party has performed discovery on a given OpenID provider identifier (and assuming everything went according to plan), it should now have the endpoint URI to which to forward users so they can accept the application permissions to access their data.

Using this endpoint, we will now go through the process of pushing the user through the auth screens to either allow or deny the relaying party from accessing his private data, as shown in Figure 12-1.

Figure 12-1. Hybrid auth, step 3: Provider requests user authentication

The process is fairly simple: the user is presented with a page on the provider site that displays the permissions that the relaying party would like to access, such as the user’s profile, friends, activities, or Attribute Exchange values from the OpenID process.

The user will either grant or deny that request and then be forwarded back to the relaying party to either process his user information or not (depending on his choice).

The initial request that the relaying party makes to the provider site includes a number of OpenID parameters (as we discussed in Chapter 11) as well as two or three OAuth-specific hybrid parameters tacked on the end to signal that it wants to trigger a hybrid auth request. Table 12-1 lists these parameters.

Table 12-1. Hybrid request parameters

Request parameter	Description
openid.ns