OpenID is an decentralized authentication mechanism for the Web. mod_openid turns Prosody into an OpenID provider, allowing users to use their Prosody credentials to authenticate with various third party websites.
mod_openid can best be described as a proof-of-concept, it has known deficiencies and should not be used in the wild as a legitimate OpenID provider. mod_openid was developed using the Prosody 0.4.x series, it has not been tested with the 0.5.x or later series.
OpenID works on the basis of a user proving to a third-party they wish to authenticate with, an OpenID relaying party, that they have claim or ownership over a URL, known as an OpenID identifier. mod_openid uses Prosody’s built in HTTP server to provide every user with an OpenID identifier of the form
http://host.domain.tld[:port]/openid/user, which would be the OpenID identifier of the user with a Jabber ID of
Simply add “mod_openid” to your modules_enabled list. You may then use the OpenID identifier form as described above as your OpenID identifier. The port Prosody’s HTTP server will listen on is currently set as 5280, meaning the full OpenID identifier of the user
email@example.com would be
mod_openid has no configuration options as of this time.
The following is a list of the pending tasks which would have to be done to make mod_openid fully featured. They are generally ranked in order of most importance with an estimated degree of difficulty.
- Support Prosody 0.6.x series (Medium)
- Refactor code (Medium)
- The code is pretty messy at the moment, it should be refactored to be more easily understood.
- Disable use of “user@domain” OpenID identifier form (Easy)
- This is a vestigial feature from the early design, allowing explicit specification of the JID. However the JID can be inferred from the simpler OpenID identifier form.
- Use a cryptographically secure Pseudo Random Number Generator (PRNG) (Medium)
- This would likely be accomplished using luacrypto which provides a Lua binding to the OpenSSL PRNG.
- Make sure OpenID key-value pairs get signed in the right order (Hard)
- It is important that the OpenID key-value responses be signed in the proper order so that the signature can be properly verified by the receiving party. This may be complicated by the fact that the iterative ordering of keys in a Lua table is not guaranteed for non-integer keys.
- Do an actual match on the OpenID realm (Medium)
- The code currently always returns true for matches against an OpenID realm, posing a security risk.
- Don’t use plain text authentication over HTTP (Hard)
- Return meaningful error responses (Medium)
- Most error responses are an HTTP 404 File Not Found, obviously something more meaningful could be returned.
- Enable Association (Hard)
- Association is a feature of the OpenID specification which reduces the number of round-trips needed to perform authentication.
- Support HTTPS (Medium)
- With option to only allow authentication through HTTPS
- Enable OpenID 1.1 compatibility (Medium)
- mod_openid is designed from the OpenID 2.0 specification, which has an OpenID 1.1 compatibility mode.
- Check specification compliance (Medium)
- Walk through the code and make sure it complies with the OpenID specification. Comment code as necessary with the relevant sections in the specification.
Once all these steps are done, mod_openid could be considered to have reached “beta” status and ready to real world use. The following are features that would be nice to have in a stable release:
- Allow users to always trust realms (Hard)
- Allow users to remain logged in with a cookie (Hard)
- Enable simple registration using a user’s vCard (Medium)
- More useful user identity page (Hard)
- Allow users to alter what realms they trust and what simple registration information gets sent to relaying parties by default.
- OpenID Bot (Hard)
- Offers all functionality of the user identity page management
- Better designed pages (Easy)
- Use semantic XHTML and CSS to allow for custom styling.
- Use the Prosody favicon.