Unexpected cookie "did" in response when requesting /oauth/token

Help
1

Greetings,

I have a team using machine-to-machine authentication involving an API that they swear has been working fine for a while now. Today, they reported an issue where the /oauth/token call returns a cookie named did, causing an error in their HTTP client with the message:

Invalid cookie header: "Set-Cookie: did=<redacted>; Max-Age=157788000; Path=/; Expires=Thu, 22 Aug 2024 21:13:00 GMT; HttpOnly; Secure". Invalid 'expires' attribute: Thu, 22 Aug 2024 21:13:00 GMT

Now, I think this is an issue with their HTTP client and advised accordingly, but I’ve been asked to figure out when/why it stopped working. Did this cookie get added recently or has it always been there? What does it do?

Here is the verbose output of a sample request:

curl -v --request POST \
  --url https://<redacted>.auth0.com/oauth/token \
  --header 'content-type: application/json' \
  --data '{"client_id":"<redacted>","client_secret":"<redacted>","audience":"<redacted>,"grant_type":"client_credentials"}'  
Note: Unnecessary use of -X or --request, POST is already inferred.
*   Trying 54.187.108.244...
* TCP_NODELAY set
* Connected to <redacted>.auth0.com (54.187.108.244) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=*.auth0.com
*  start date: Jul 23 00:00:00 2019 GMT
*  expire date: Aug 23 12:00:00 2020 GMT
*  subjectAltName: host "<redacted>.auth0.com" matched cert's "*.auth0.com"
*  issuer: C=US; O=Amazon; OU=Server CA 1B; CN=Amazon
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7fdc61805e00)
> POST /oauth/token HTTP/2
> Host: <redacted>.auth0.com
> User-Agent: curl/7.54.0
> Accept: */*
> content-type: application/json
> Content-Length: 217
> 
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
* We are completely uploaded and fine
< HTTP/2 200 
< date: Fri, 23 Aug 2019 16:11:27 GMT
< content-type: application/json
< content-length: 854
< server: nginx
< ot-tracer-spanid: 2c2d0970376a1eaa
< ot-tracer-traceid: 4640f2dc740f82e8
< ot-tracer-sampled: true
< cache-control: no-store
< x-auth0-requestid: 4538551f8a6840cdd723
< set-cookie: did=<redacted>; Max-Age=157788000; Path=/; Expires=Thu, 22 Aug 2024 22:11:27 GMT; HttpOnly; Secure
< x-ratelimit-limit: 1000000
< x-ratelimit-remaining: 999999
< x-ratelimit-reset: 1566576688
< pragma: no-cache
< strict-transport-security: max-age=15724800
< x-robots-tag: noindex, nofollow, nosnippet, noarchive
< 
* Connection #0 to host <redacted>.auth0.com left intact
{"access_token":"<redacted>","expires_in":86400,"token_type":"Bearer"}
2

We’re seeing a similar issue right now that hasn’t happened before.

3

We ran into the same issue. Only thing I found that references did and did_compat

4

Hello,

As far as I know, this is not a problem with Auth0 API but with Apache HttpClient <= 4.

It uses a DEFAULT CookieSpec policy, which does not play well with Auth0 Expires cookie header. Setting the CookieSpec to STANDARD_STRICT (which became the default in HttpClient 5) or upgrading to HttpClient 5 wilk make the warnings disappear from your logs!

In Spring Boot, I configured it that way:

var requestConfigWithStrictCookies = RequestConfig.custom().setCookieSpec(CookieSpecs.STANDARD_STRICT).build();
var requestFactoryWithStrictCookies = new HttpComponentsClientHttpRequestFactory(
  HttpClients.custom().setDefaultRequestConfig(requestConfigWithStrictCookies).build()
);

return new RestTemplateBuilder()
  .rootUri(domain)
  .requestFactory(() -> requestFactoryWithStrictCookies);

Hope this helps