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, 2013 at 16:31
  • @SteveS You're right. Though I think UProve by Microsoft may help with this in non-browser scenarios. Mar 13, 2013 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, 2013 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) Mar 21, 2013 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?
    – MCW
    Mar 21, 2013 at 18:51

1 Answer 1


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)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .