Question

I’m about to create a datatbase table to store OpenID logins. I think I will include these three columns, in addition to the Claimed Identifier:

• The OpenID endpoint
• The OP-Local Identifier
• The realm
• The OpenID version (1 or 2)

Do you store these fields?

Do you think it’s reasonable to store these fields?, for the following reasons:

• The OpenID endpoint: So you know which OpenID Provider authenticated the user. Perhaps in the future you’ll find out that one provider is not so very trustworthy, and then I think it’s good to know if someuser.example.com was authenticated by that provider.

• The OP-Local Identifier: I think it allows me to keep track of the user, even if she changes her User-Supplied Identifier. (For example, if her User-Supplied Identifier is example.com/username, but she changes it to somewhereelse.com/username, then I think the OP-Local Identifier will remain unchanged (assuming the user continues using the same OpenID Provider).

• The realm: I’m building a multitenant webapp, and if I store the realm, it’ll be easier to know if two seemingly different OpenID identifiers might represent the same person. (Google uses directed identities: your Claimed ID varies by realm. So the same user can have many different Claimed IDs.)

• The version: In case some security issue appears in the future, with some OpenID version, then it might be good to know which users might be affected.

• The realm and endpoint, for statistics gathering purposes.

(Can you think of some other OpenID related value I ought to store? For example, I want to identify provider. To do this, it suffice to store the endpoint? I don’t need to store the provider’s name?)

Answer 1

• The OpenID endpoint: Trustworthy? How is a provider trustworthy (or not)? It isn’t asserting anything about the data it doesn’t own, so it can’t possibly lie. Whether it behaves as you expect it to is another thing whatsoever. Besides, a provider could, for some reason, have different endpoints for each user (for example, /server-username).
• The OP-Local Identifier: You shouldn’t (because the specification says so), but yes, in a very small number of cases, it would be successful. However, it is much more often to change your provider than to change your identity. And if you really want to change your identity, changing the provider (or registering a different account) isn’t that hard. One case where it would help would be when the user would lose the domain name that hosts the claimed identity. However, it is much more likely for the provider to stop offering it’s services, and you also need to prepare for that (for example, by offering to store multiple IDs for a single user, like SO). And if you’re prepared for it, the single case where it would help is covered by another mechanism.
• The realm: I don’t see how would that help you. From Google, you get two completely separate identifiers, with no possibility to correlate them, unless you require an email address (and why would you need the realm, then?).
• The version: Unlikely, and the version may change with the new request (because a provider might update). Nevertheless, if you really want to know which of your users might be affected, and somehow expect them to gain anything by reading about that on your website, then yes, it could be useful.

You’ve said that you want to identify the provider. However, as I’ve mentioned above, it’s not possible to do so if the provider takes steps to avoid that. You could, for example, store it’s domain name, but that’s not perfect, since there might be other providers under the same domain (for example, several people hosting their own providers on a shared hosting).

In summary, my opinion is that storing these is a bad idea, for reasons stated above.