OpendID security tips for Asp.net

Question

Hello,

I am just starting with OpenID in an Asp.net MVC application and was wondering what some of the pitfalls are when using OpenID. The reason why I am asking is because I read a lot of warnings when using some OpenID implementations. Mostly it's something like "Don't use that library! You just need to change one word in the url and your site is open to anybody!!!!"

I will most likely end up using DotNetOpenAuth but as a beginner some of the therms that are used seem a little foreign. That's also one of the reason why I made this question because ignorance isn't going to make my application very secure.

Since there isn't one correct answer I hope making this question 'community wiki' is the right thing to do. If this sort of question isn't allowed I'll delete it right away.

Thanks in advance,

Pickels

Answer 1

DotNetOpenAuth isn't one of those "change one word and it's broken" libraries. It's a good one to use.

As far as terminology:

• ClaimedIdentifier is the new username. Treat it as case sensitive and make sure your database does case sensitive matching when you look up user records based on it. Do not consider http and https URLs that are otherwise identical as the same user -- they must be considered entirely different.
• User supplied identifier is the literal string the user typed into the OpenID box (if there is one). Never, ever treat anything here as authoritative and don't make security decisions based on it. Wait until you get a ClaimedIdentifier from the response and make decisions based on that, and the ProviderEndpoint.
• OP Endpoint (aka Provider endpoint) is the URL of the OpenID Provider's OpenID endpoint, and you can make decisions on that if you want to trust only certain Providers.
• Claims, such as email address and full name of the user may come from the Provider if you request those attributes. But never trust that as correct unless the claims comes from an OP Endpoint you trust.

Answer 2

I can't speak about existing .NET projects, but I can provide explanation of the basics for a beginner. Although there are some edge-cases and optional functionality, the basic flow is not difficult to understand. OpenID-enabled service providers ("Relying Parties" or RP) effectively off-load the password-checking functionality of authentication to a 3rd party web site ("Identity Provider", or IdP). A (end-user specific) URL to such an IdP is specified by the end-user and (from the point of view of the RP) this URL is the end-user's "Identifier". The RP makes a server-side call to the Identifier URL to get a activity token, and then bounces the browser to the Identifier URL. Now the end-user is interacting with the IdP, and when the IdP is satisfied, it bounces the browser back to the RP with some info tacked onto the query string to indicate success. Voila.

Because the user gets to decide who verifies their identity, they can even choose a service that uses some entirely different authentication mechanism, like calling them up on the phone, or even requiring a thumbprint through a connected device. Alternatively, if they don't trust anyone else in the world, they can program their own IdP and have total control over their identity.

Many times (not here on SO) an RP will actually make the Identifier public throughout the service, e.g. as the end-user's username. Therefore, it's fashionable to use a vanity URL or a blog URL, or something more meaningful than http://superopenidprovider.com/adjad9va8ivasdlkjnq8t7 . So there exists the concept of IdP delegation, through which an end-user that includes on their homepage/blog appropriate LINK tags to http://superopenidprovider.com/adjad9va8ivasdlkjnq8t7, can use their homepage/blog URL as their Identifier. RPs must be aware of this functionality and take appropriate action.

High-level concepts

Roughly from Wikipedia. These are more conceptual than Andrew's answer.

• End-user The person who wants to assert his or her identity to a service provider.
• Identity The service provider-specific information related to a single end-user. I.e. all the stuff an end-user identifies with and wants to protect.
• Identifier The end-user specific URL supplied by the end-user, with which OpenID authentication can be initiated.
• Relying party (RP) A service provider that uses OpenID to determine the veracity of an end-user's identity claim.
• Identity provider (IdP) website that can respond to OpenID authentication requests from Relying Parties, usually involving password-based challenge/response with the end-user via web forms and cookies. IdPs typically support multiple users, and thus allow end-users to register and manage Identifiers through the site. However, an individual can host their own IdP which only authenticates themselves.