Please paste the ldif for your client configuration.

Not sure what you mean by Idif.

Hi, Paul. That means you need to do a LDAP search in the Gluu's internal directory (inside of the container). Please provide output of this command to us: ` ``` # echo YOUR_LDAP_PASS > ~/.pw # /opt/opendj/bin/ldapsearch -h localhost -p 1636 -D 'cn=directory manager' -j ~/.pw -Z -X -b 'o=gluu' 'inum=YOUR_CLIENT_ID'` # rm ~/.pw ``` `YOUR_LDAP_PASS` should be the same as you default admin password.

So I've spent the good par of an hour trying to get the above command to work. Someone else installed this server on a VM so that's making things harder. However I don't think the information that command is necessary to answer this support question. If you look at RFC6947 section 3.2.1 it states... >Clients in possession of a client password MAY use the HTTP Basic authentication scheme as defined in [RFC2617] to authenticate with the authorization server. **The client identifier is encoded using the"application/x-www-form-urlencoded" encoding algorithm per Appendix B, ** The Nimbus client API I'm using also includes a statement in it's javadoc stating the same that the CLientID and Client Secret should be URLEndcoded. ``` * Returns the HTTP Authorization header representation of this client * secret basic authentication. * * <p>Note that OAuth 2.0 (RFC 6749, section 2.3.1) requires the client * ID and secret to be {@code application/x-www-form-urlencoded} before * passing them to the HTTP basic authentication algorithm. This * behaviour differs from the original HTTP Basic Authentication * specification (RFC 2617). * * <p>Example HTTP Authorization header (for client identifier * "Aladdin" and password "open sesame"): * * <pre> * * Authorization: Basic QWxhZGRpbjpvcGVuK3Nlc2FtZQ== * </pre> * * <p>See RFC 2617, section 2. * * @return The HTTP Authorization header. */ public String toHTTPAuthorizationHeader() { StringBuilder sb = new StringBuilder(); try { sb.append(URLEncoder.encode(getClientID().getValue(), UTF8_CHARSET.name())); sb.append(':'); sb.append(URLEncoder.encode(secret.getValue(), UTF8_CHARSET.name())); } catch (UnsupportedEncodingException e) { // UTF-8 should always be supported } return "Basic " + Base64.encodeBase64String(sb.toString().getBytes(UTF8_CHARSET)); } ``` If you look at the code they are urlencoding authortization header components first before encoding it with Base64. For a test I created two clients one that does the urlencoding with Nimbus and another that skips the urlencoding step. The second client works with the GLUU server (it produces an Authorization header that the server is able to decode and match with a client). So I think the GLUU server is not doing the urldecoding first.

The Gluu Server passes all the conformance test: [http://openid.net/certification/](http://openid.net/certification/) It's rather unlikely that we got something like URL encoding wrong. Unless we can verify that your client configuration is correct, there is no point looking further.

Just a thought.. From what I can see in specs, "x-www-form-urlencoded" encoding should only actually change "client_name+client_secret" string in any way if it contains some regular characters from beyond of ASCII character set, or if it contains so called ["unsafe" characters](https://perishablepress.com/stop-using-unsafe-characters-in-urls/). As we use stings like `!@xxx.xxx...` for client's name, and as "@" character is in the list of those unsafe characters and thus must be encoded, if there indeed would be an issue with encodings, we should have been experiencing the issue for every OIDC-using website. So, we must conclude, that some OIDC RP implementations Gluu was tested with, like `mod_auth_openid`, also don't do this encoding correctly? Btw, do you use any non-ASCII, or "unsafe" characters in your client's secret string, Paul? If you do, could you re-test with another client secret, containing only ASCII characters (or just make them only numbers, for simplicity)?

BTW, you should try Gluu's client software: [https://oxd.gluu.org](https://oxd.gluu.org) We can send you a trial license. One of the several advantages is that we can provide more end-to-end support on our client.

That's fine, however I just want to point out that I didn't say the GLUU server was doing URLencoding wrong, I said it was skipping the URLEncoding step before doing the base64 encoding in the Basic Client Secret. The old RFC didn't specify this but the updated RFC does. In any case, thanks for the help. Paul

Hi Aliaksandr, My client secret is just simple ascii characters. That part of the authorization code matches with either case. Paul

Understood, thanks. Please note that we are limiting community support to list of RPs provided [here](https://www.gluu.org/blog/limiting-openid-connect-community-client-support/), which includes both our **oxd** framework and `mod_auth_openidc` mentioned before. If you'll still be able to reproduce this issue using one of those, that should be considered a bug. Otherwise, it's just unlikely that several different RP implementations copy the same erroneous behaviour of Gluu you described (otherwise it won't be able to come up with the same strings when comparing credentials in the end).

Remember, we are more concerned with compliance to OpenID Connect spec then OAuth2. If they diverge (which they should not...) it's unfortunate.