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.
Table of contents
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!)