Token refresh fails with error "os_authType was 'any' and an invalid cookie was sent."

[Martin W]

Since upgrading to Confluence Data Center 9.2.8 from 9.2.7 we are failing to obtain an access token using the authentication flow outlined here.

We are able to pass the consent stage to obtain an initial token but all subsequent requests using the refresh token fail with a tomcat error stating "os_authType was 'any' and an invalid cookie was sent.".

We are failing to understand where a cookie comes into play during an OAuth flow.

[Peter_DevSamurai · Accepted solution]

Hi @Martin W ,

That "os_authType was 'any' and an invalid cookie was sent" error is triggered when a request to a protected endpoint (like /rest/oauth2/latest/token) includes an invalid or unexpected session cookie, and the config prioritizes cookie auth before falling back to others like Basic. You can try sen refresh without cookies:

- Use a fresh HTTP client/tool without session state (e.g., curl, Postman with no cookie jar).

- Authenticate with Basic Auth: Base64-encode client_id:client_secret for the Authorization header.

- Use cURL (below is the example, you should adjust with ur parameters):

curl -X POST https://your-confluence.com/rest/oauth2/latest/token \
-H "Authorization: Basic $(echo -n 'client_id:client_secret' | base64)" \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "grant_type=refresh_token&refresh_token=your_refresh_token&redirect_uri=your_redirect_uri"

-> this should succeed if the token is valid. (Similar article: OAuth 2.0 throws "os_authType was 'any' and an invalid cookie was sent" )

If this doesn't resolve (like server-side config issue), check seraph-config.xml for the token endpoint. You can consider setting os_authType=basic for /rest/oauth2/** (requires restart, test carefully). Or contact Atlassian Support with logs (enable debug for com.atlassian.seraph).

I hope everything works out for you!

Best,

Peter

[Martin W]

Hi @Peter_DevSamurai ,

Thanks for the quick response.
I can confirm that disabling state management in the HTTP client fixes this issue for us.

For reference for anybody else who may encounter this the solution was to disable cookie management using this functionality of Apache HttpClientBuilder.

Thanks again for your assistance.

[Peter_DevSamurai]

I'm glad I was able to assist! Have a great week ahead