CODEWITHSUNDEEP
securityposthttpsheaderopenid-connect
Patrick M
Patrick M

Reputation: 10989

Is an HTTPS header or a post body more secure?

When sending an HTTPS request, is there any difference from a security standpoint between a header and the post body? Is one more vulnerable to leaking or interception? If so, why?

I have read comparisons of GET vs. POST and of various authentication and encryption schemes against each other, but nothing about Header vs. application/x-www-form-urlencoded Post bodies. I admit I only spent ~20 minutes googling and SO searching, so apologies if this has been covered before.

While I believe this to be generic to all HTTPS traffic, I'm asking in the context of OpenId Connect. I am using the Authorization Code grant type and the Spring Security OAuth client libraries.

OIDC stipulates Clients and Authorization Servers have a choice of method for sending credentials when exchanging a one-time code for a durable id token. Quoting openid.net openid-connect-core section 9. Client Authentication:

This section defines a set of Client Authentication methods that are used by Clients to authenticate to the Authorization Server when using the Token Endpoint. During Client Registration, the RP (Client) MAY register a Client Authentication method. If no method is registered, the default method is client_secret_basic.

These Client Authentication methods are:

client_secret_basic
Clients that have received a client_secret value from the Authorization Server authenticate with the Authorization Server in accordance with Section 2.3.1 of OAuth 2.0 [RFC6749] using the HTTP Basic authentication scheme.

Note, this is the Authorization: Basic <value> header. The provider I'm integrating with supports this via OpenId client_id and client_secret concatenated with a colon and Base64 encoded.

client_secret_post
Clients that have received a client_secret value from the Authorization Server, authenticate with the Authorization Server in accordance with Section 2.3.1 of OAuth 2.0 [RFC6749] by including the Client Credentials in the request body.

I have not been able to find anything specific to OpenId Connect that expresses a preference between either method.

I am integrating with a OIDC provider that allows either method, but you must choose and all dependent resource servers must conform to the single choice. Both the header and post body are sent in plain text. (Note this provider does not support either the client_secret_jwt method which is HMAC SHA encoded version of the sensitive secret or the private_key_jwt method which is a public-private signature, both of which are clearly more secure than essentially plaintext values, but it's unclear if this adds any practical security improvement on a TLS/SSL encrypted communication.)

Upvotes: 5

Views: 3699

Answers (2)

Kavindu Dodanduwa
Kavindu Dodanduwa

Reputation: 13069

While Pieter pointed on the specification, I also have a thought on the best practice.

Given a post body can contain any information, there is no way browsers, proxy implementations or an API to respect secrets embedded in body. In comparison, Authorisation header is defined and maintained by RFC7235, which is a standard.

4.2. Authorization

The "Authorization" header field allows a user agent to authenticate itself with an origin server -- usually, but not necessarily, after receiving a 401 (Unauthorized) response. Its value consists of credentials containing the authentication information of the user agent for the realm of the resource being requested.

More on proxy,

A proxy forwarding a request MUST NOT modify any Authorization fields in that request. See Section 3.2 of [RFC7234] for details of and requirements pertaining to handling of the Authorization field by HTTP caches.

So being a well understood header by many parties should make it the safest way to transmit credentials. Hope this thought will help others to make their design decisions.

Upvotes: 2

Pieter Ennes
Pieter Ennes

Reputation: 2409

OAuth 2.0 prefers HTTP Basic auth and states the following about this:

Including the client credentials in the request-body using the two parameters is NOT RECOMMENDED and SHOULD be limited to clients unable to directly utilize the HTTP Basic authentication scheme (or other password-based HTTP authentication schemes).

You can safely assume that this translates to OIDC as well.

Upvotes: 5

Related Questions