Are you a developer thinking about using OpenID?

Disclaimer

This page contains recommendations and tips for developers who have already implemented OpenID consumers and/or producers. If you want help building one for the first time, it depends largely on which language you choose and which library. Here is a list of libraries.

Tips for OpenID consumers
Linking to us
Using our form
Tips for OpenID providers

Tips for OpenID consumers

Have OpenID icon in the input field: it's the standard, and it helps users visually identify where they should put an OpenID and where not to. So, even if you've put the icon elsewhere on the page, please also put it in the input field itself. You can download the icon from OpenID.net in various formats.
Link to an explanation of OpenID: We highly recommend that everyone who implements OpenID include some sort of user-friendly explanatory link. We think that our site does a good job of explaining OpenID, and have tried to make it as seamless as possible for users. You can read more below about linking to us.
Don't make them get a username and password: that defeats much of the purpose of OpenID! And, it confuses users who have learned that OpenID means that they don't need a new username and password for each website.
Limit the amount of information that users have to fill out: again, much of the point of OpenID is to make signing up and in easier for users. Get as much info as you can from OpenID to auto-fill some fields in. That will make the lives of your users much better and your website much more appealing to them.

Linking to us

To make life easier on your users, we will supply a link back to your login page. To do this, we give you the option of sending us the following variables (via GET) :

OID_consumer_address (the URL to send them back to)
OID_consumer_name (the name of your website, so they know to where the link leads)
OID_consumer_icon (the address of an icon for your website, which will appear next to the name)

You can also include these in a shorter form as:

OIDCA (the same as OID_consumer_address)
OIDCN (the same as OID_consumer_name)
OIDCI (the same as OID_consumer_icon)

All other variables you send to us (via GET) will get sent back identically when the user returns. So, if a user has started filling out your form and then clicked a link to OpenIDExplained.com, you can send us the information they've already filled out, and when the user returns to your website, we'll send it back to you (to auto-fill the fields they've already worked on). (Note: please don't send us any unencrypted data for obvious privacy reasons.)

In addition, if the user has filled out our form on the "How Do I Get an OpenID?" page, we'll send that to you as well with the GET variable:

OID_consumer_user

Using our form

If you like the form on the "How Do I Get an OpenID?" page, we welcome you to use it as a tool for new OpenID users to get acquainted with the system (this is not meant as a replacement for the regular OpenID field, just a way to ease people into OpenID).

We have a page that accesses our Database and returns XML, JSON, or Text depending on your preference. It is located at:

http://www.openidexplained.com/get_provider

It can handle two types of queries:

to get an OpenID for a given username and provider
to get a list of popular OpenID providers and a schema for getting a user's OpenID for each

Query (1) expects (via GET) :

type (expects 'XML','JSON', or 'text', not case-sensitive; the output will be returned in this format, default is 'XML')
username (the user's username)
domain (the domain, must be equivalent to the domain on our form or it won't match)

Query (1) will return:

x refers to the user's OpenID

For XML: <url>x</url>
For JSON: { "url": "x" }
For text: x

Query (2) expects (via GET) :

type (expects 'XML','JSON', or 'text', not case-sensitive; the output will be returned in this format, default is 'XML')
length (expects a numeric value for the number of providers to return, default is all)

Query (2) will return:

p1,p2,p3,... refer to provider names

u1,u2,u3,... refer to URL schema (see below)

XML

<providers>
	<provider>
		<domain>p1</domain>
		<url>u1</url>
	</provider>
	<provider>
		<domain>p2</domain>
		<url>u2</url>
	</provider>
	...
</providers>

JSON

{"providers":
	{"provider": [
		{"domain": "p1","url": "u1"},
		{"domain": "p2","url": "p2"},
		...
	]}
}

text

p1,u1,p2,u2,...

URL Schema

A URL Schema looks exactly like a valid OpenID, except that it has the string %s where the username should go. So, the schema for LiveJournal is %s.livejournal.com. Once you get the user's username, you replace %s with it, and you have her or his OpenID.

Tips for OpenID providers

Use our query scheme for keeping track of who sent the user to you: (We're referring to the scheme in (1) that lets you pass GET variables to keep track of info about the user and the OpenID consumer.) If we can develop a spec for storing this kind of information, it could make signing up and logging in even easier for users. One of developers' concerns about OpenID is that it sends their users away from them, which is especially aggravating if the user has already filled in some information. Letting consumers pass in a link back to themselves and whatever (encrypted!) user information they are willing to give you so that you pass it back to them when the user returns to their website would alleviate both of these concerns.
Tell people their OpenID: It's wonderful that so many websites are giving their users OpenIDs, but those OpenIDs aren't actually useful unless the users know about them. So, please, let the user know that they have an OpenID with you, and what it is! (We're looking at you LiveJournal and AOL!)

OpenID Explained← Return to the front page