views:

479

answers:

5

I'm planning to add openid support for a web application I'm building. I can't seem to find the maximum length of a valid openid so I can store it in my database. I've seen some vague references to 255 but I'd rather be sure.

In addition is it useful to use the openid as the username (recommendations)?

+5  A: 

an OpenID is a URI, so you are limited by the maximum length of a URI. As far as I know there is no limit, but some browsers (such as Internet Explorer) have a limit.

Further reading:

http://openid.net/pipermail/general/2008-August/005305.html

Nippysaurus
Thanks that was useful.
Ruggs
Your link indicates that the maximum length of an Identifier Uri in OpenId 2.0 is currently unspecified. The maximum length of a URL is also unspecified, but different browsers have different limits. Internet Explorer currently has the shortest limit, 2083 characters. http://support.microsoft.com/kb/208427
dthrasher
+2  A: 

I would not use the OpenID directly as the username. Just have a look at the OpenID URLs that Yahoo provides to users, they're incomprehensible. Allow users to choose their own username, and ideally allow multiple OpenID URLs to be associated with one user account (like Stack Overflow does).

Greg Hewgill
I will be storing the openid in a separate table from the user database so it will support multiple openids.
Ruggs
+1  A: 

There isn't an official length in version 2.0 of the spec.

You can hash the URL provided into something unique (md5, or some other repeatable hash) and store that in your DB as a much shorter string.

As for using it as a username, a big url is not pretty. You can extract a username from the responses (SO got my username directly from my OpenID)

Darryl E. Clarke
I never thought of storing it as a hash. That makes sense.
Ruggs
REALLY bad idea. MD5 and SHA-1 have been broken, so I could hack into your RP as anyone I wished just by contriving a claimed id that hashed to the same value. You _could_ mitigate this by uniquely salting each hash, but it's by far bes to just store the whole thing.
Andrew Arnott
So how would you send the md5/sha-1 hash from the provider? OpenID responses must come from the trusted provider to be valid in the first place.
Ruggs
I'm not talking about sending the hash to or receiving it form the provider. I'm also not talking about the hash being shown anywhere to a front-end user. I'm merely talking about storing it as a means of using less DB storage, with a fixed, calculated size rather than an unknown length of any URL. The user will always have to provide a valid URL to login, my application would then validate using proper OpenID methods and then store a hash of the URL as a reference only.
Darryl E. Clarke
It's still a bad idea. Yes, your application will still require the user to prove he owns an OpenID URL, but your application will still have to look in its local database to determine which local account that URL grants access to. If the database only stores hashes, any user who knows my OpenID can craft their own OpenID whose hash matches mine, and gain access to my account.
Forest
+1  A: 

You should not accept any OpenID URL that is longer than 255. While it is possible, many can use this as an attack vector to pull off things like SQL Injection. Take a look at the OWASP AntiSAMY APIs as an additional protection.

jm04469
+3  A: 

According to the specification for OpenId 1.1, the maximum limit for Identifier Urls is 255 bytes. See OpenId 1.1 Appendix D: Limits. Identity Provider and return_to Urls may be up to 2047 max bytes.

Note that this section on limits was removed from the OpenId 2.0 specification. So it's unclear what the maximum length is now.

dthrasher