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.
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 |
|---|---|
| The OpenID namespace URI to be used. For instance, this should be http://specs.openid.net/auth/2.0 for OpenID 2.0 transactions. |
| The transaction mode to
be used during the auth process. The possible values are
If the
user should be able to interact with the OpenID provider, then
|
| The claimed OpenID identifier, provided by the user. |
| 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. |
| A handle for an association between the relaying party (implementing site) and the OpenID provider that should be used to sign the request. |
| The location where the user should be returned, with the OpenID response, after authentication has taken place. Many web-based providers may require this field. If this field is not included, it indicates that the relaying party does not want to return the user after authentication. |
| The URL pattern for the domain that the user should trust. For instance, *.mysite.com. If |
| The OpenID OAuth extension namespace. This value should be set to http://specs.openid.net/extensions/oauth/1.0. |
| The consumer key provided when you create a new OAuth application with the provider. |
| Scopes (the data that the application would like to access from the user) that may be required for the OAuth process. Some providers may bind scopes directly to the consumer key once the application is created, in which case this parameter is not required. |
Many of the parameters required for the request are familiar from the OpenID authentication flow. For the hybrid auth flow, the three additional request parameters are:
openid.ns.oauthopenid.oauth.consumeropenid.oauth.scope
The user will be forwarded to the provider site to accept the permissions being requested from him, which brings us to the next step in the process.