Module openid.consumer.consumer

OVERVIEW

1. The user enters their OpenID into a field on the consumer's site, and hits a login button.
2. The consumer site discovers the user's OpenID server using the YADIS protocol.
3. The consumer site sends the browser a redirect to the identity server. This is the authentication request as described in the OpenID specification.
4. The identity server's site sends the browser a redirect back to the consumer site. This redirect contains the server's response to the authentication request.

LIBRARY DESIGN

This consumer library is designed with that flow in mind. The goal is to make it as easy as possible to perform the above steps securely.

At a high level, there are two important parts in the consumer library. The first important part is this module, which contains the interface to actually use this library. The second is the openid.store.interface module, which describes the interface to use if you need to create a custom method for storing the state this library needs to maintain between requests.

In general, the second part is less important for users of the library to know about, as several implementations are provided which cover a wide variety of situations in which consumers may use the library.

STORES AND DUMB MODE

OpenID is a protocol that works best when the consumer site is able to store some state. This is the normal mode of operation for the protocol, and is sometimes referred to as smart mode. There is also a fallback mode, known as dumb mode, which is available when the consumer site is not able to store state. This mode should be avoided when possible, as it leaves the implementation more vulnerable to replay attacks.

The mode the library works in for normal operation is determined by the store that it is given. The store is an abstraction that handles the data that the consumer needs to manage between http requests in order to operate efficiently and securely.

Several store implementation are provided, and the interface is fully documented so that custom stores can be used as well. See the documentation for the OpenIDConsumer class for more information on the interface for stores. The implementations that are provided allow the consumer site to store the necessary data in several different ways, including several SQL databases and normal files on disk.

IMMEDIATE MODE

In the flow described above, the user may need to confirm to the identity server that it's ok to authorize his or her identity. The server may draw pages asking for information from the user before it redirects the browser back to the consumer's site. This is generally transparent to the consumer site, so it is typically ignored as an implementation detail.

USING THIS LIBRARY

Integrating this library into an application is usually a relatively straightforward process. The process should basically follow this plan:

Add an OpenID login field somewhere on your site. When an OpenID is entered in that field and the form is submitted, it should make a request to the your site which includes that OpenID URL.

To start, the application should get an OpenIDConsumer instance, and call its begin method. This method takes the OpenID URL and, optionally, a session object. If the application has any sort of session framework that provides per-client state management, that should be used here. The library just expects the session object to support a dict-like interface, if it provided. If no session object is provided, the application code needs to store the information that would have been put in the session in an alternate location. See the documentation for the begin call for more information. The begin method returns an OpenIDRequestBuilder object.

Next, the application should call the buildRedirect method on the OpenIDRequestBuilder object. The return_to URL is the URL that the OpenID server will send the user back to after attempting to verify his or her identity. The trust_root is the URL (or URL pattern) that identifies your web site to the user when he or she is authorizing it. Send a redirect to the resulting URL to the user's browser.

That's the first half of the authentication process. The second half of the process is done after the user's ID server sends the user's browser a redirect back to your site to complete their login.

When that happens, the user will contact your site at the URL given as the return_to URL to the buildRedirect call made above. The request will have several query parameters added to the URL by the identity server as the information necessary to finish the request.

Get an OpenIDConsumer instance, and call its complete method, passing in all the received query arguments and either the user's session object or the token saved earlier. See the documentation for OpenIDRequestBuilder for more information about the token.