UserInfo: protecting access token (GET vs POST)

Question

I've noticed when using the official Postman collection, the parameters for any methods have to be put as parameters in the URL, otherwise the status code received is 400.

I've tried debugging it, so I transformed the request into a curl command for comparison. The following two examples are based on Query for User Information endpoint.

Example No. 1 returns status code 400 (parameters sent in the body):

curl --location --request GET login.salesforce.com/services/oauth2/userinfo --header 'Content-Type: application/x-www-form-urlencoded' --header 'Cookie: BrowserId=usq7aOP-Ee2-kNv2ky7zDw; CookieConsentPolicy=0:0; LSKey-c$CookieConsentPolicy=0:0' --data-urlencode 'access_token={access token}'

Error message:

{
    "error": "unsupported_grant_type",
    "error_description": "grant type not supported"
}

Example No. 2 is equivalent to the previous one, except the parameters are in the URL and returns 200:

curl --location --request GET login.salesforce.com/services/oauth2/userinfo?access_token={access token} --header 'Content-Type:application/json' --header 'Cookie: BrowserId=usq7aOP-Ee2-kNv2ky7zDw; CookieConsentPolicy=0:0; LSKey-c$CookieConsentPolicy=0:0'

Can anyone help me understand what is the problem here? I understand that sending the parameters in the URL is working, but since the body is in the x-www-form-urlencoded format, it would be much more secure to send the request in this format.

Answer 1

The UserInfo resource is specified in OpenID Connect (OIDC) Core:

5.3.1. UserInfo Request

The Client sends the UserInfo Request using either HTTP GET or HTTP POST. The Access Token obtained from an OpenID Connect Authentication Request MUST be sent as a Bearer Token, per Section 2 of OAuth 2.0 Bearer Token Usage [RFC6750].

It is RECOMMENDED that the request use the HTTP GET method and the Access Token be sent using the Authorization header field.

The following is a non-normative example of a UserInfo Request:

GET /userinfo HTTP/1.1   
Host: server.example.com   
Authorization: Bearer SlAV32hkKG

While the OIDC Core spec allows UserInfo via a POST, very few OIDC providers support this. Most (including Salesforce) implement it as a GET with the token sent via the Authorization header. SF UserInfo doc:

You can use the access token in an authorization request header or in a request with the oauth_token parameter.

Trying it:

curl -X GET https://login.salesforce.com/services/oauth2/userinfo --header 'Content-Type: application/x-www-form-urlencoded' --header 'Authorization: Bearer ...'

yields an expected response:

{
"sub": "https://login.salesforce.com/id/.../...",
"user_id": "...",
"organization_id": "...",
...
}

Is sending the access token in the header or query parameter with GET more risky than POSTing it in the body? It depends on the threat model. For the very basic consideration of your client sending it to the Salesforce server, the major threat is transport - the pipe from your client to Salesforce. Since TLS is required on UserInfo endpoint and TLS protects the entire request (headers, query params, etc), the transport risk is identical for GET vs POST.