According to the OAuth 2.0 spec ([RFC 6749](https://tools.ietf.org/html/rfc6749), section [2.3.1](https://tools.ietf.org/html/rfc6749#section-2.3.1)) When using Basic Authentication for client authentication, the `Client ID` and `Client Secret` must **first** be individually [URL-encoded](https://tools.ietf.org/html/rfc6749#appendix-B) before they can be used for Basic Authentication, see: [RFC 2617, Section 2](https://tools.ietf.org/html/rfc2617#section-2). In simple terms, OAuth 2.0 client authentication requires **additional work** to be done by both the client (URL-encoding) and authentication server (URL-decoding) when using HTTP Basic Authentication. This requirement for two-step encoding/decoding is further clarified in a July 2016 [RFC errata entry](https://www.rfc-editor.org/errata_search.php?rfc=6749&eid=4749), which changes Section [2.3.1](https://tools.ietf.org/html/rfc6749#section-2.3.1) to read (**_change emphasized_**): > Clients in possession of a client password MAY use the HTTP Basic authentication scheme as defined in [RFC2617](https://tools.ietf.org/html/rfc2617) to authenticate with the authorization server. The client identifier is encoded using the "application/x-www-form-urlencoded" encoding algorithm per [Appendix B](https://tools.ietf.org/html/rfc6749#appendix-B), and the encoded value is used as the username; the client password is encoded using the same algorithm and used as the password. **_The url encoded values are then encoded as defined in [RFC2617]_**. The authorization server MUST support the HTTP Basic authentication scheme for authenticating clients that were issued a client password. And includes the following note by the author: > It was not clear to some implementers that the intention is a 2-step encoding. First for special characters and second the 2617 base 64 encoding. Implementers thought 6749 was in conflict with 2617. ### Example: - **Client ID:** `@!12AD!0008!6D30.23D7` (note the `@` and `!`) - **Client Secret:** `P@55W0rd!` Must be URL-encoded to be used for Basic Authentication's `user-id` and `password`: - **RFC 2617 userid:** `%40%2112AD%210008%216D30.23D7` - **RFC 2617 password:** `P%4055W0rd%21` When combined (`userid:password`), and then base64 encoded as defined in [RFC 2617 Section 2](https://tools.ietf.org/html/rfc2617#section-2): - **RFC 2617 user-pass:** `%40%2112AD%210008%216D30.23D7:P%4055W0rd%21` - **RFC 2617 base64-user-pass:** `JTQwJTIxMTJBRCUyMTAwMDglMjE2RDMwLjIzRDc6UCU0MDU1VzByZCUyMQ==` Produce the OAuth 2.0-**compliant** header field: - `Authorization: Basic JTQwJTIxMTJBRCUyMTAwMDglMjE2RDMwLjIzRDc6UCU0MDU1VzByZCUyMQ==` The 3.1.1 version of Gluu does not URL-decode the `userid` and `password` values extracted from the Authorization HTTP request header before using them as the `Client ID` and `Client Secret`, which means the following, not-fully-decoded values are used for authentication: - **Client ID:** `%40%2112AD%210008%216D30.23D7` - **Client Secret:** `P%4055W0rd%21` Which fails. ### Work Around If neither the `Client ID` nor `Client Secret` contain special characters (which would have been encoded by URL-encoding) then Authentication **will still succeed**, thereby seeming to be compliant. Unfortunately, Gluu's auto-generated OIDC `Client ID`s (`Inum`s) do contain special characters, however the `Inum` can be _carefully_ modified in the LDAP server using a tool such as [Apache Directory Studio](http://directory.apache.org/studio). ### Summary I believe that Gluu (and likely oxd-java, but I haven't tested it) are **not** in compliance with the OAuth 2.0 specification because it does not correctly handle Basic Authentication for client authentication. See also: - [https://github.com/GluuFederation/oxAuth/issues/677](https://github.com/GluuFederation/oxAuth/issues/677) - [https://support.gluu.org/authentication/4908/token-endpoint-with-basic-authentication-fails-due-to-not-url-decoding/](https://support.gluu.org/authentication/4908/token-endpoint-with-basic-authentication-fails-due-to-not-url-decoding/) References: - [https://tools.ietf.org/html/rfc6749](https://tools.ietf.org/html/rfc6749) - [https://tools.ietf.org/html/rfc2617](https://tools.ietf.org/html/rfc2617)