Identification by URL

OpenID has demonstrated an approach to identification: identifying by URL.


To start this discussion, we'll look at some of the nice things that can be done when using this method:

Centralized where advantageous

Multiple websites can be accessed using one authentication mechanism.

Decentralized where advantageous
Power to the people

By using OpenID delegation, a webmaster can point to their own web page, and have that web page point to a provider of OpenID services. If there was ever trouble with that provider of OpenID services, then the webmaster could select another provider of OpenID services and then change the web page. All websites that rely on that web page will then effectively end uip using the newer provider of OpenID services.

This gives substantial power to any webmaster who has complete control over the web pages on the webmaster's website. The webmaster can also use static HTML, which simply means that the webmaster doesn't need to set up any sort of server-side technologies. This is relatively simple, and this guide will show how to do that.

Flexible authentication methods

The provider of the OpenID services will have an opportunity to interact with the end user. It is up to the provider of the OpenID services to determine how the authentication takes place. This means that technologies like biometrics could be used (at least, in theory). Meanwhile, the site that is seeking authentication (which is known as the “relying party”, as this party relies on the authenication that may be provided by other organizations) is only required to simply support OpenID. This “relying party” does not need to do anything to support fancy customizations. So, if one website is an “OpenID provider” and does something awesome, and multiple “relying party” websites rely on that OpenID provider, then a user can experience that awesomeness when logging into multiple different “relying party” websites, and the “relying party” websites didn't need to do anything to permit that.



There are various implementations/levels of OpenID. These may include: OpenID Authentication 1.1, OpenID Authentication 2.0, OpenID Connect 1.0, OAuth 2.0. It was originally “referred to as Yadis (an acronym for "Yet another distributed identity system")”, as quoted by Wikipedia's page for OpenID.

This guide currently does not provide a very extensive overview about the technologies. However, this guide does provide a bit of a walkthrough. Getting an OpenID states, “Delegation is the simplest way to get up and running with OpenID. Delegation requires nothing more than an OpenID Provider and some basic HTML.” Actually, the easiest way is to just use another organization as a provider, which is noted in the “Getting an OpenID” section of the guide to: Delegating with OpenID. However, delegating is presumably the easiest way to use your own website as a URL. (That doesn't require actaully running a program to be an OpenID provider.) Details about doing delegation are provided by a guide to: Delegating with OpenID.

If you wish to be your own provider, there are multiple options. At the time of this writing, this text is not endorsing/recommending any one of these specific options, but just provides a mention of these options as a convenient reference.

readwrite: OpenID Status Check: A Guide to Getting and Using Your OpenID mentions some resources, including (an old address for) wiki about acting as your own provider and the phpMyID. IndieWebCamp: “How to set up OpenID on your own domain”: section titled “Installing on your own server” mentions that phpMyID is a single file. The Getting an OpenID refers to JanRain (Identity Service) or OpenID Developers page. One nice thing about wiki about acting as your own provider is that it mentions licenses, at least for some of the options.