Cookie not sent on redirection. Is Referer the culprit?

Question

I've got an HTTP server that implements the client side of OpenID Connect. The OpenID Connect protocol involves a number of redirections and one of them is giving me trouble, possibly due to the presence of the Referer header. The problem occurs with Firefox, Chrome and IE.

1. A request comes to my server. The browser is redirected to an OpenID Provider.
2. The OpenID Provider authenticates the end-user and redirects the browser to an endpoint on my server.
3. My server interacts with the OpenID Provider to determine the end-user's identity and establish a session for the user.
4. The browser is redirected back to my server to re-execute the original request, this time with a session id in a cookie.

I've created a simple OpenID Connect Provider implementation for testing and everything works fine. But when testing with salesforce.com, there is a problem with the final redirection in step 4. When salesforce.com is used, the final request does not contain a Cookie header.

---

Testing with my OpenID Connect Provider

The response sent to user's browser in step 4:

HTTP/1.1 302 Found
Set-Cookie: session=c925f5006beb15cab779b292fe37e727; path=/; secure; HttpOnly
Location: https://localhost:21201/targetService
Content-Type: text/html; charset=UTF-8
Content-Length: 75

The browser comes back with:

GET /targetService HTTP/1.1
Host: localhost:21201
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.97 Safari/537.36
DNT: 1
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8
Cookie: session=c925f5006beb15cab779b292fe37e727

That looks good and the request is honored. The requested resource is returned with a 200 status.

---

Testing with salesforce.com

The response sent to user's browser in step 4:

HTTP/1.1 302 Found
Set-Cookie: session=5c6980f0ca3a1860b66880c836865eb0; path=/; secure; HttpOnly
Location: https://localhost:21200/targetService
Content-Type: text/html; charset=UTF-8
Content-Length: 75

The browser comes back with:

GET /targetService HTTP/1.1
Host: localhost:21200
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.97 Safari/537.36
DNT: 1
Referer: https://na16.salesforce.com/setup/secur/RemoteAccessAuthorizationPage.apexp?source=CAAAAVKuWovcME8wODAwMDAwMDAwMDA0AAAAxrM5iJVLBE88gApP096QhF5f83j0HN8ziJiIAdQEiiPmEiBfkMSrZVdxHPiO0EmDxIeKxZCkfidhCpaB4sEOkTNXsBjtNOE3NuhngS-cU8NPzTGM5aSnS8GiPgfui_7SvRh0y6jfFqYg_WkIh0RDK9u7KQjuz4VsFy5lJ2wBP0tyKSmpKSoXVCSxiwwcRZJbCjZVxWwiwodVVf5YfgAOpJ8fF64-swwZNxzi7-ZpTPPZVBIJtxaO_VKIDbrRH9BnaIoo7FRld4P0pYmlh7SOk4I5YhibW_dc-NqQ8YHj7EXv9EMc0Zk2PFDfP8QJV1LJ_pdu-UzpI-r78JTMQlZeF6OC2ANaMGykEyD9BI7cFNKu6UD1MljaiRCcEuMdqP2n7s0yFmRt1o-wl9gSIY6BHq_0LshPlC_quufFA6qFwLEperjE3LZ78JBYLUTLFAlzM1GeGEh75MADZZqvWQE7DTbrvYcB29Q0tMK2jC22FTp8GqfxgSD5UBirfCWjfLDkDccII2g1AwteoH0tBTwhNUQqA2bb8Tl7aRQ_vIHxRboN9h5WlSpZEqphiq_FJAL1F3bPoicoSCvFDxYzQj-SrlY%3D&display=page
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8

As you can see, the browser responds to the redirection by sending the next request with no cookie. Because there is no cookie, my server redirects the browser to the OpenID Provider for authentication, starting an endless loop.

The only difference I can see is that the final request, when testing with salesforce.com, includes a Referer. I suspect this may be causing it to not include the cookie. Is that the case? If so, any ideas on what I can do about it. Obviously, I cannot control what salesforce.com does.

Answer 1

As it turns out, Referer is not the culprit. I discovered that you can disable use of the Referer header in Firefox. I did so and am still getting the same result. When redirected after returning from salesforce.com, the browser does not honor the Set-Cookie header. That is, it is still not sending the cookie in step 4 of the original post.

So, the problem is not yet resolved, but this question has been answered.