OpenId authentication vulnerability

0
votes

I have implemented OpenId authentication some time ago and to remember users I used ClaimedIdentifier (in the terms of DotNetOpenAuth) - the string returned by OpenId provider after authentication.

But suddenly I understood this solution has a vulnerability. Let's imagine there is OpenId provider 1 that returns identified "identifier1" for user 1. Now if I know this identifier I can start up my custom OpenId provider and return the same identifier - so I will be able to login under the user 1.

Now I am thinking about storing openid_identifier (the OpenId provider url) + ClaimedIdentifier.

Am I right in my thinking? Haven't I missed any other possible vulnerability?

1
openiddotnetopenauth

1 Answers

2
votes

This vulnerability you've thought of is not a vulnerability, actually. The OpenID protocol itself (and thus the DotNetOpenAuth library) includes protections against an arbitrary OpenID Provider asserting an identifier that it does not own. So no, not only do you not need to store the OP Endpoint (what you called the OpenId provider url) alongside the Claimed Identifier, but if you did so, you'd break some of the flexibility of OpenID.

You may be asking at this point, so how does it work then? Why isn't this a vulnerability?
The answer comes from the fact that any time a Provider (OP) asserts a Claimed Identifier to a Relying Party (RP), the RP doesn't just trust the OP. It has no reason to trust the OP because as you said, anyone can set up an arbitrary OP. Instead, the RP takes the claimed identifier and performs discovery on it. Essentially the RP is asking the claimed identifier "does OP foo.com have authority to assert your identity?" Only the true OP for a given claimed identifier will be able to get the identifier to say "yes" to this question. A "no" response would cause the RP to reject the assertion and tell the user there was an error during authentication.