This is a living document, intended to list the current security best practices for Users, Relying Parties, and OpenID Providers. OpenID security discussions should be held on the OpenID Security Mailing List.  While this is a wiki, please first discuss your proposed change on the mailing list to help this page remain high quality.

Security Best Practices for Users

Because OpenIDs can be used to sign into multiple websites, the value of an OpenID increases with each additional site that the OpenID is used. Users should take precautions to ensure that their account at their OpenID Provider is safeguarded against being compromised, including having a strong password, and keeping their account information up to date.

Users should consider taking advantage of additional authentication options offered by their OpenID Provider, including using a client certificate to sign in, 2 factor authentication, or other stronger authentication options.

Users who authenticate with a password at their OP should always be vigilant against phishing. Users should only enter their password on their OP's Login screen, and should verify that the URL displayed in their browser's address bar is the URL of their OpenID Provider. Users should be aware of other hints to recognize their OP's Login screen, as documented by their OP, including checking that their browser's HTTPS icon is displayed if their OP supports HTTPS, and setting up a personalized icon on the the Login screen.

If the user's OpenID Provider offers an HTTPS identifier, the user should log into RPs with the https:// prefix to their identifier to better secure their account with that RP against DNS poisoning attacks.

Users should never share their password with sites that want to import their data. Users should demand that sites use a delegated authorization protocol, such as OAuth, to share their data without sharing their password.

When using a shared computer, users should remember to sign out of their OpenID Provider before giving up control of the computer. As long as the computer has an active browser session with the user's OpenID Provider, anyone can sign in as that user at OpenID RPs.  The user should also take care to log out of each RP he/she logged into, since logging out of the OP doesn't automatically log the user out of RPs.

Security Best Practices for Relying Parties

RPs should always protect against XSS attacks against their local authentication cookies and protect against XSRF attacks. Any URL that updates data on the user's behalf, or changes the state of the user's account MUST be XSRF protected.

Instead of implementing the OpenID Protocol from scratch, RPs are strongly encouraged to use an existing library, such as one of the open source libraries listed on OpenID.net.

Relying Parties should not create authentication sessions which persist longer than the authentication session at the user's OpenID Provider. Relying Parties should periodically call the OpenID Provider's checkid_immediate interface to verify that the user is still signed into their OpenID Provider

To Do:  Recomendation on the duration of the RP's authentication session, and the frequency to call checkid_immediate?  If the user didn't check 'Automatically sign me into this RP' at the OP during login checkid_immediate will fail.  Is this sound advice?

Relying Parties SHOULD implement RP Discovery by publishing a discovery document discoverable under their Realm which lists their OpenID endpoints. RP Discovery helps OpenID Providers verify the legitimacy of an authentication request.

Relying Parties should not use OpenID Assertions to authorize transactions of monetary value if the assertion contains a PAPE message indicating that the user authenticated with Assurance Level NIST Level 0.

Relying Parties must trust the OpenID Provider to authenticate the user in manner consistent with the Replying Party's security policies. Relying Parties should use the PAPE Extension to communicate to the OpenID Provider the security policies required to authenticate the user. However, the relying party must trust that the OpenID Provider properly implemented the requested security policies. The actual mechanism for how Relying Parties can trust an OpenID Provider is outside the scope of this document.

Users may be silently signed into the RP's site using XSRF against the RP's Login screen to force a checkid_immediate request to the user's OP.

When linking an existing account with an OpenID, the Relying Party MUST authenticate the user (most commonly by verifying the user's password) before linking the accounts.  When adding multiple OpenIDs to the same user account, each added OpenID MUST be taken through the login process to prove that the user controls that identifier.

Relying Parties implementing the OpenID Protocol on their own should be aware of the following potential issues:

• Association Poisoning - RPs MUST key their associations with an OpenID Provider endpoint.
• Signatures are NOT optional, the openid.sig value MUST be verified on every OpenID Response, and should be protected against replay attacks by verifying the nonce.
• Directed Identity - Relying Parties MUST use the OpenID returned in the Authentication Response, rather than the string that the user entered, as the user's OpenID.
• OpenID URL Fragments - Relying Parties MUST use the entire OpenID, including the optional fragment, as the identifier for the user. As specified in the Identifier Recycling section of the OpenID 2.0 Specification, OpenID Providers MAY recycle identifiers, however, the fragment portion of the identifier is not recycled.
• When comparing Claimed Identifiers (for example, to look up a user account for someone who has just completed logging in using OpenID), the check MUST be case sensitive for the entire path, query and fragment parts.  The host part MAY be case insensitive.

Best Practices for OpenID Providers

OpenID Providers that use passwords to authenticate users MUST require that their password verification form be displayed in an independent browser window or popup, with the address bar displayed. OpenID Providers are strongly encouraged to educate their users about the dangers of phishing, and how to recognize the OP's login screen.

OpenID Providers should use HTTPS for their login screen. Password submission should always be over HTTPS.

OpenID Providers MUST not allow their Login or Approval screens to be framed by the RP. Allowing the Login or Approval screens to be framed makes the approval flow vulnerable to clickjacking, and trains users to expect the URL Location bar to not have the OPs URL, leaving them vulnerable to phishing.

OPs which use passwords to authenticate their users should deploy anti-password cracking defenses to prevent automated guessing of passwords. A common technique is to require the password to be submitted with a CAPTCHA after a certain number of invalid password submissions.

OpenID Providers are highly encouraged to issue HTTPS Identifiers to their users.  And if HTTPS identifiers are available, the non-SSL HTTP identifier SHOULD either not resolve to a Claimed Identifier OR should redirect to the HTTPS identifier. 

Providers MAY wish to return OpenID identity pages for any and all URLs matching their claimed identifier URL format, regardless as to whether a user account exists for that page to avoid giving away user data about existing/non-existing accounts to unauthorized clients.

Users should opt-in to allowing checkid_immediate for each RP that they want to automatically sign into. OPs should NOT enable checkid_immediate for RPs that the user had not previously signed into. OPs must allow users to opt-out of checkid_immediate after they have opted in.

The checkid_immediate interface, as defined in the OpenID 2.0 specification, can be exploited as an open redirector on the OpenID Provider's domain. OpenID Providers wishing to avoid hosting an open redirector on their domain can host their OpenID endpoints on alternate domain, or they can verify that the checkid_immediate is running within a frame before returning the response.  Although the OpenID 2.0 specification does not require checkid_immediate to run within a frame, it is believed that most RPs using checkid_immediate are using it within a hidden iframe.

OpenID Providers which give Relying Parties a choice of  authentication policies to authenticate the user should use the PAPE Extension to specify which policy to use.

Contributors

The content of this document is based on discussions held on the OpenID public mailing lists, and from conversations held at events including the Internet Identity Workshop.

Allen Tom (Editor)

Andrew Arnott