views:

49

answers:

2

I have implemented a straightforward OpenID support for my ASP.NET app with DotNetOpenAuth. Yet I recently realized that the implementation was treating http://johndoe.example.com/ as a distinct user compared to https://johndoe.example.com.

This lead to quite a few confused users. I am unsure what to do at this point. Is this a bug or a feature?

Indeed, I can consider this behavior as a feature: if the user specifies the HTTPS, the user might not want the system to accept HTTP auth in the first place.

On the other hand: if the user specifies HTTPS out of sheer cluelessness (the casual web visitor is clueless concerning the purpose of the "S" part), then rejecting it's authentication attempt is confusing.

What is considered as the best practice?

A: 

Theoretically http and https identities could be different. Practically (as implemented by the providers in the real world) they shouldn't be.

StackOverflow does not differentiate between http://abdullin.myopenid.com and https://abdullin.myopenid.com, so the solution should probably work for the 99% scenarios.

Rinat Abdullin
StackOverflow is wrong to treat them equivalently (if that's true). See Steven's answer.
Andrew Arnott
+4  A: 

Yes - they are completely different and should be treated as so.

The recommendations to OP's is to always use https but that isn't always the case (just now).

Some OPs do only offer HTTPS identifiers, including Yahoo and Google, I believe.
keturn
This is a security requirement. If HTTP and HTTPS identifiers are treated as equivalent, then HTTPS provides no greater security than HTTP, and is therefore vulnerable to DNS poisoning, which equals user identity spoofing (read: stolen identity). It is VERY important that you treat these as different identities.
Andrew Arnott