I need to outsource authentication to an IdP (Identity Provider) but I don't want that IdP to know of the calling site. The two major issues are the callback URL and the referer header.

Is there any way to "hide" or mask the callback URL, referer header and any other data that may exist?

Some ideas might include

  • Using javascript to HTTP POST
  • Using an object such as ActiveX, or add-in
  • Adapting Mozilla Persona to the idea (unless it already does it)
  • Callback to a proxy that simply hops and anonymizes the traffic

Is anyone aware of a way to authenticate a site using a 3rd party, hide the source site's identity?

  • 4
    Umm. The IdP needs to know the caller, otherwise it doesn't know where to return the token. In any case, any transfer from one page to another should induce a referrer header. – Steve Mar 11 '13 at 16:31
  • @SteveS You're right. Though I think UProve by Microsoft may help with this in non-browser scenarios. – goodguys_activate Mar 13 '13 at 21:10
  • UProve is pretty well dead. It was a neat technology but it was also (IMO) a nonstarter because it required browser extensions. – Steve Mar 20 '13 at 23:56
  • @SteveS I contacted MSFT research 3 days ago and they will have an announcement "soon" re UProve. Also, their last UProve demo was 14 months ago, so I don't think sufficient idle time has passed to declare something dead unless you know something. (Besides, isn't everything an "extension" when you think about it: HTML5, CSS, etc ... a standard gets written and incorporated. UProve is FOSS so it's possible) – goodguys_activate Mar 21 '13 at 5:43
  • Privacy is not the same as anonymity. I think this is an XY question. You've asked a question about privacy, and then you've made a variety of assumptions about how to implement. We could examine either the question or the answer; which are you really looking for? – Mark C. Wallace Mar 21 '13 at 18:51

I do not think that it will be a good idea to hide the identity of Service provider(SP) from the Identity Provider (IdP- a trusted third party).

  1. The IdP is providing authentication as a service to SPs that integrate with it.
  2. This comes under federated identity management which is entirely dependent on establishing trust relationships between different domains.
  3. This enables the end users to authenticate themselves with one domain (IdP) and access services which belong to different domains (Single sign-on)
  4. Since the IdP is providing a service to SP It should have a mechanism to identify the SP from which the authentication request is coming from. and to verify the authenticity of the request. (generally implemented by verifying the digital signature of the SP and some kind of prior agreement between the two parties)

Let us say you (SP) do not want to share your identity information with IdP.

  1. After checking for the user's credentials how will the IdP notify the SP that the user is authenticated or not (callback URL is needed)
  2. If there is no strong method to identify the requesting party, some malicious web application may pretend to be you and communicate with the IdP.This may result in compromise of some important information.
  3. Let us consider an extreme case where you are relying on a third party to communicate with the IdP on your behalf. Even then you need to have some mechanism to verify the authenticity of the authentication request.(again you need to share your public key)
| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.