OpenID notes

From Helpful
Revision as of 14:54, 19 June 2024 by Helpful (talk | contribs) (Created page with "{{stub}} ====Short version==== See [http://simonwillison.net/2006/openid-screencast/ this video], it's pretty clear on the basics. ====What it is==== In the more functional sense, OpenID * lets you have an identity on an OpenID provider * that you can use to sign on to many other websites Any such participating client site mostly just cares to have someone give them an identity, and have someone say that's really them (authenticate that identity). What you giv...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

Short version

See this video, it's pretty clear on the basics.


What it is

In the more functional sense, OpenID

  • lets you have an identity on an OpenID provider
  • that you can use to sign on to many other websites


Any such participating client site mostly just cares to have someone give them an identity, and have someone say that's really them (authenticate that identity).


What you give that site an OpenID (which is an URL).

That site then knows who to contact (the URL) and how (OpenID).

As far as that site is concerned, the exchange is roughly:

  • site using OpenID: "Hey, specific OpenID server (based on openid) - this person particularopenid is trying to log in. Do you agree that's them?"
  • OpenID server: "Hmm, particularopenid? Let's see (checks with you), Yes that's them / no it's not."


That check will happen on the OpenID provider site (it will often mean the browser going to the provider site, and you logging into it).

Which means (importantly) that the OpenID client never sees the login information, or means of login.


This is one way of solving the password anti-pattern, for personal logins.

---

The limitation you may have already realized is that it solves identity verification only to the degree that clients can trust the OpenID provider.

Some random server is vouching for you, but that only knows that site knows you. In fact, that might just be your personal site.


The check proves that the identity described by the URL that is is indeed verified. (There is a bunch of security detail about going from site to site that side of things can for the most part be fairly simply trusted.)


Just how much that server's verification actually means to that client site, however, depends on the trust it places in the openID provider.

OpenID in itself is only useful to identify users that wish to return as the same identity.




Technically, OpenID servers are identity brokers and verifiers.


OpenID is decentralized in the sense that there is no master OpenID server. (Anyone can start one, but only serious one will be trusted by you).

It's centralized in that any one OpenID points at the provider it comes from.

The OpenID itself is basically an URL that points to said provider, which is how an OpenID client knows what server to contact for verification.

What it isn't

It does not really deal with trust - the only thing you really get is the information on whether a specific exchange succeeded.


Implicit (and pre-configured) trust in a system is always a bad idea (human trust is often one of the weakest links in a security system). To get back to the vouching-for-someone analogy: you would likely accept a good friend vouching for someone else, but probably not someone who's opinion you've come to disagree with, or a stranger. If some company vouches, you would still make some quick risk assessments and consider how their policies have worked out in the past.


A login in a decentralized login (OpenID or otherwise) is limited by:

  • The verifier's trustability.
Consider an openID server spam.com that answers 'yes' to each and every request that comes in.
  • Certain implementation details
OpenID allows setup of aliases, such as using a short domain name as an OpenID (by making it point to one). This means that this identity can change, e.g. when I lose the domain and someone else registers it.
OpenID allows clients to check whether it is verifying the same actual ID as before, but they have to actually do so to be secure against this.

Still, OpenID does make a number of things harder to fake. For example, if you got a comment or account request from spock.oid.example.com, and I can (informally) check that the person I'm thinking of indeed owns that openID, and that oid.example.com is trustworthy, that means they signed it.

Basic usage details

Signing up for an identity means a provider hands you a single URL that represents your identity.


This identity itself implies the site at which it the identity can be verified, which means login at a site you've never been before at involves:

  • typing your identity, such as example.myopenid.com
  • You get forwarded to the site that can verify this identity -- in this case myopenid.com
  • you log into your openid provider,
  • it tells you the new site wants access,
  • you allow it,
  • you get sent back to the new site

To the casual observer, it's a username/password deal, just at a central site.


OpenID has two main uses that I've noticed. The first is being the login step for an account elsewhere. This may well imply choosing a screen name there that is unrelated. This use is purely private, for my own ease of login.

The other is leaving a comment that is provably mine, say, on a blog (such as on livejournal -- except I have an account there anyway)


Identity delegate on a page

There are several openID providers, but you may not like some company's name in your ID. While you could technically run your own openID service, that's not very practical.

Something that is a lot easier is using a specific website -- usually a domain you own, to keep it short, or perhaps the URL to your main blog -- that you have control over.


Consider that losing control over that domain or website means that a different identity may eventually sit at the same openID url. If you stop owning that site, it is not guaranteed another identity won't be put there.

In fact, this is a feature too: since you delegate to a real openID service, you can change the delegate to another OpenID when for some reason you want to swith accounts, say, your openID service disappears.


This does not equal identity theft, but it's similar. That identity cannot log into the things you created from there(verify), but if you relied on people seeing this as your 'real' identity, well, you have a problem.


OpenID providers

Some services imply an openID. For example, Livejournal users have an openID, period. AOL is implementing openIDs, and microsoft said it would too. Using one of these may be simpler. You can of course have several openIDs.

As to provider services, there are many. See http://openid.net/wiki/index.php/Public_OpenID_providers


Sites you can use OpenID on

Also a big list, and growing quickly. See https://www.myopenid.com/directory


http://www.gnucitizen.org/blog/openid-a-security-story/


Unsorted

http://www.openid-ldap.org/ (OpenID provider based on LDAP authentication)