OIDC Endpoint in violation of RFC6749 #63
Description
I know that this might not be 100% the correct place to leave this issue - but since linkedin.zendesk.com is only taking care of Talent Solutions APIs and this library includes code to work around the offending issue, I'm leaving this issue here, hoping that you might be able to escalate the issue internally.
https://www.linkedin.com/oauth/.well-known/openid-configuration defines the configuration of LinkedIn's OIDC provider - it should be a pretty easy thing to implement a client to connect to LinkedIn given the correct credentials and API access.
However, there is one issue here: According to official documentation, the Token-endpoint should be POSTed to not only with a payload consisting of grant_type, code and redirect_uri, but also client_id and client_secret.
That in itself is not really problematic - except that the above linked discovery-/configuration document does not make note of this.
Section 2.3.1 of RFC6749 says:
The authorization server MUST support the HTTP Basic
authentication scheme for authenticating clients that were issued a
client password.
Alternatively, the authorization server MAY support including the
client credentials in the request-body using the following
parameters:
[...]
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). The parameters can only
be transmitted in the request-body and MUST NOT be included in the
request URI.
RFC 8414 specifies
token_endpoint_auth_methods_supported
OPTIONAL. JSON array containing a list of client authentication
methods supported by this token endpoint. Client authentication
method values are used in the "token_endpoint_auth_method"
parameter defined in Section 2 of [RFC7591]. If omitted, the
default is "client_secret_basic" -- the HTTP Basic Authentication
Scheme specified in Section 2.3.1 of OAuth 2.0 [RFC6749].
Since the openid-configuration does not include the token_endpoint_auth_method property, client_secret_basic must be assumed.
But the correct solution would be for the openid-configuration to be present, and to be set to client_secret_post.
I came across this issue since we using a standard-conforming OIDC-client on our platform which exclusively works by parsing the configuration document. Unless LinkedIn was to add the missing property, we would need to implement a "manual, LinkedIn is not following RFC, override/workaround"... I'd hope not to have to do this ;-)
This change should not be breaking for your existing customers, since apparently everyone is either running custom implementations just for LinkedIn, or following the NOT RECOMMENDED part part of the RFC...
Thank you for your consideration!