An experiment in implementing OpenID Connect
Switch branches/tags
Nothing to show
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.


Connect Me

Here's an experimental implementation of OpenID Connect I wrote to try to decide if it's really the flagrant power grab for my web identity by big sites that it feels like.

What is it?

OpenID Connect is a proposed new version of OpenID that is based on OAuth 2. This implementation comprises two web applications:

  • is a web app that you can sign into with OpenID Connect (a "relying party").
  • is a web app that serves OpenID Connect identities.

Due to the constraints designed into OpenID Connect, the server must run at the top level of a domain over SSL that is reachable from the server. (I ran on my local desktop, and on a development server reachable from my desktop.)

Setting it up

To run it, you'll need several Python modules:

You can pip install -r requirements.txt to get good versions of these.

You'll also need Perlbal to run in front of the server to handle decrypting the SSL. As cribbed from LiveJournal's guide, you can make a self-signed certificate with:

$ openssl req -x509 -newkey rsa:1024 -keyout connectme-key.pem -out connectme-cert.pem -days 365 -nodes

Using it

Once both servers are running, view the website in your browser. Enter the URL or domain name of the website to begin logging in. (You'll then be asked to ignore the self-signedness of the server's cert.) Once you're on the site, enter the username with which to identify to the OpenID Connect client. You'll then be returned to the web site, which will greet you with the identifier including the username you entered.

Future work

As an experiment, this implementation is incomplete in several important ways:

  • finishes after getting the access token and identifier from the server; a real implementation would make the request to the protected resource at the identifier to get all the available profile information.
  • The server asks you at the authorization step as whom to identify to the client; a real implementation would have accounts.
  • Both the client and server only support JSON; a real implementation would probably support the other available serializations, maybe.
  • The server only produces bearer tokens; a real implementation would provide an access token secret when asked by the client, for use with non-https protected resources.

However it illustrates the basic flow of OpenID Connect.