Package openid :: Package server :: Module server
[frames] | no frames]

Module server

source code

OpenID server protocol and logic.


An OpenID server must perform three tasks:

  1. Examine the incoming request to determine its nature and validity.
  2. Make a decision about how to respond to this request.
  3. Format the response according to the protocol.

The first and last of these tasks may performed by the decodeRequest and encodeResponse methods of the Server object. Who gets to do the intermediate task -- deciding how to respond to the request -- will depend on what type of request it is.

If it's a request to authenticate a user (a checkid_setup or checkid_immediate request), you need to decide if you will assert that this user may claim the identity in question. Exactly how you do that is a matter of application policy, but it generally involves making sure the user has an account with your system and is logged in, checking to see if that identity is hers to claim, and verifying with the user that she does consent to releasing that information to the party making the request.

Examine the properties of the CheckIDRequest object, optionally check CheckIDRequest.returnToVerified, and and when you've come to a decision, form a response by calling CheckIDRequest.answer.

Other types of requests relate to establishing associations between client and server and verifying the authenticity of previous communications. Server contains all the logic and data necessary to respond to such requests; just pass the request to Server.handleRequest.

OpenID Extensions

Do you want to provide other information for your users in addition to authentication? Version 2.0 of the OpenID protocol allows consumers to add extensions to their requests. For example, with sites using the Simple Registration Extension, a user can agree to have their nickname and e-mail address sent to a site when they sign up.

Since extensions do not change the way OpenID authentication works, code to handle extension requests may be completely separate from the OpenIDRequest class here. But you'll likely want data sent back by your extension to be signed. OpenIDResponse provides methods with which you can add data to it which can be signed with the other data in the OpenID signature.

For example:

   # when request is a checkid_* request
   response = request.answer(True)
   # this will a signed 'openid.sreg.timezone' parameter to the response
   # as well as a namespace declaration for the openid.sreg namespace
   response.fields.setArg('', 'timezone', 'America/Los_Angeles')

There are helper modules for a number of extensions, including Attribute Exchange, PAPE, and Simple Registration in the openid.extensions package.


The OpenID server needs to maintain state between requests in order to function. Its mechanism for doing this is called a store. The store interface is defined in Additionally, several concrete store implementations are provided, so that most sites won't need to implement a custom store. For a store backed by flat files on disk, see For stores based on MySQL or SQLite, see the module.


From 1.0 to 1.1

The keys by which a server looks up associations in its store have changed in version 1.2 of this library. If your store has entries created from version 1.0 code, you should empty it.

From 1.1 to 2.0

One of the additions to the OpenID protocol was a specified nonce format for one-way nonces. As a result, the nonce table in the store has changed. You'll need to run contrib/upgrade-store-1.1-to-2.0 to upgrade your store, or you'll encounter errors about the wrong number of columns in the oid_nonces table.

If you've written your own custom store or code that interacts directly with it, you'll need to review the change notes in

An object that knows how to handle association requests with no session type.
An object that knows how to handle association requests with the Diffie-Hellman session type.
I am a response to an OpenID request in terms a web server understands.
I sign things.
I encode responses in to WebResponses.
I encode responses in to WebResponses, signing them when required.
I decode an incoming web request in to a OpenIDRequest.
I handle requests for an OpenID server.
A message did not conform to the OpenID protocol.
Raised when an operation was attempted that is not compatible with the protocol version being used.
Raised when a response to a request cannot be generated because the request contains no return_to URL.
Could not encode this as a protocol message.
This response is already signed.
A return_to is outside the trust_root.
The return_to URL doesn't look like a valid URL.
The trust root is not well-formed.
I represent an incoming OpenID request.
A request to verify the validity of a previous response.
A request to establish an association.
A request to confirm the identity of a user.
I am a response to an OpenID request.
  BROWSER_REQUEST_MODES = ['checkid_setup', 'checkid_immediate']
  UNUSED = None
    HTTP Codes
  HTTP_OK = 200
  HTTP_ERROR = 400
    Response Encodings
  ENCODE_KVFORM = ('kvform')
  ENCODE_URL = ('URL/redirect')