OpenID Connect: invalid_client on authorization_code request

By: Chris MacDonald user 24 Aug 2016 at 12:48 p.m. CDT

11 Responses
Chris MacDonald gravatar
I'm using the NodeJS passport-openid-connect package as a client to authenticate against our Gluu server. My authentication flow gets stuck trying to get the authorization_code because of an invalid_client. The flow goes as follows (line breaks in URLs added for readability): - User navigates to webapp - User clicks login in webapp - User is redirected to our Gluu server with query string: ``` https://gluu/oxauth/seam/resource/restv1/oxauth/authorize? response_type=code &client_id=%40!4692.354C.6746.1845!0001!0171.D8FA!0008!FC70.AB27 &redirect_uri=https%3A%2F%2Fwebapp%3A3443%2Fv1%2Fauth%2Fopenid%2Freturn &scope=openid%20profile ``` - User logs in with Gluu credentials and allows webapp access to the specified scopes - User is redirected to the webapp's callback URL with the code: ``` https://webapp:3443/v1/auth/openid/return? session_state=b17d1e51-4eab-4e85-b1c3-9bc90fea8c41 &scope=openid &state &code=6e43419e-8321-43ad-916d-27866329c06c ``` - Web server makes a POST request to get the authorization_code: ``` Header: 'Content-Type: application/x-www-form-urlencoded' URL: https://gluu/oxauth/seam/resource/restv1/oxauth/token Body: grant_type=authorization_code &redirect_uri=https%3A%2F%2Fwebapp%3A3443%2Fv1%2Fauth%2Fopenid%2Freturn &client_id=%40!4692.354C.6746.1845!0001!0171.D8FA!0008!FC70.AB27 &client_secret=b7252e16-a2c0-4548-94a8-f769fd0f1f00 &code=6e43419e-8321-43ad-916d-27866329c06c ``` - Gluu server responds with HTTP Code 401: ``` { "error":"invalid_client", "error_description":"Client authentication failed (e.g. unknown client, no client authentication included, or unsupported authentication method). The authorization server MAY return an HTTP 401 (Unauthorized) status code to indicate which HTTP authentication schemes are supported. If the client attempted to authenticate via the Authorization request header field, the authorization server MUST respond with an HTTP 401 (Unauthorized) status code, and include the WWW-Authenticate response header field matching the authentication scheme used by the client." } ``` I have tried creating the clients both ways: - the Gluu admin web UI (https://gluu/identity/client/manage/add) - a curl request to the dynamic registration endpoint: ``` curl -H "Content-Type: application/json" -X POST -d '{"redirect_uris":["https://webapp:3443/v1/auth/openid/return"], "client_name":"Test", "scopes": ["openid", "profile"] }' https://gluu/oxauth/seam/resource/restv1/oxauth/register ``` Response: { "client_id": "@!4692.354C.6746.1845!0001!0171.D8FA!0008!FC70.AB27", "client_secret": "b7252e16-a2c0-4548-94a8-f769fd0f1f00", "registration_access_token": "423576da-a17b-4b6a-b44c-190ee7290505", "registration_client_uri": "https://gluu/oxauth/seam/resource/restv1/oxauth/register?client_id=@!4692.354C.6746.1845!0001!0171.D8FA!0008!FC70.AB27", "client_id_issued_at": 1472053885, "client_secret_expires_at": 1472140285, "redirect_uris": ["https://webapp:3443/v1/auth/openid/return"], "response_types": ["code"], "application_type": "web", "client_name": "TestAuto", "subject_type": "public", "id_token_signed_response_alg": "RS256", "token_endpoint_auth_method": "client_secret_basic", "require_auth_time": false, "logout_session_required": false, "scopes": [ "openid", "profile" ] } Please help point me in the right direction. Thanks, Chris MacDonald Edit: Formatting. Edit 2: Bad copy/paste on code.
U1404
closed

Answers

By Michael Schwartz Account Admin 24 Aug 2016 at 1:47 p.m. CDT

Copy
Michael Schwartz gravatar
Can you paste in the LDIF for the client? ``` /opt/opendj/bin/ldapsearch -h localhost -p 1636 -Z -X -D "Cn=directory manager" -j ~/.pw -b "o=gluu" -s base 'inum=@!4692.354C.6746.1845!0001!0171.D8FA!0008!FC70.AB27' ``` BTW, write the admin PW to `~/.pw` (and remove when you're done).

By Chris MacDonald user 24 Aug 2016 at 2:01 p.m. CDT

Copy
Chris MacDonald gravatar
As-is, returned nothing at all. Dropping "-s base": ``` # /opt/opendj/bin/ldapsearch -h localhost -p 1636 -Z -X -D "Cn=directory manager" -j ~/.pw -b "o=gluu" 'inum=@!4692.354C.6746.1845!0001!0171.D8FA!0008!FC70.AB27' dn: inum=@!4692.354C.6746.1845!0001!0171.D8FA!0008!FC70.AB27,ou=clients,o=@!4692 .354C.6746.1845!0001!0171.D8FA,o=gluu objectClass: oxAuthClient objectClass: oxAuthClientCustomAttributes objectClass: top oxAuthScope: inum=@!4692.354C.6746.1845!0001!0171.D8FA!0009!F0C4,ou=scopes,o=@!4 692.354C.6746.1845!0001!0171.D8FA,o=gluu oxAuthClientIdIssuedAt: 20160824155125.530Z oxAuthGrantType: authorization_code oxPersistClientAuthorizations: false oxLastLogonTime: 20160824155125.531Z oxAuthRegistrationAccessToken: 423576da-a17b-4b6a-b44c-190ee7290505 oxAuthResponseType: code oxAuthTrustedClient: false oxAuthAppType: web oxAuthLogoutSessionRequired: false oxAuthSubjectType: public oxAuthRequireAuthTime: false oxAuthClientSecret: mPRICT0BIDzWBv+7kDMaZG7vce+5dYrEqvEm1FHzVvB20L1FH/ArIA== oxAuthClientSecretExpiresAt: 20160825155100.000Z oxAuthTokenEndpointAuthMethod: client_secret_basic oxAuthIdTokenSignedResponseAlg: RS256 oxLastAccessTime: 20160824172916.062Z oxAuthRedirectURI: https://<gluu-server>:3443/v1/auth/openid/return displayName: TestAuto inum: @!4692.354C.6746.1845!0001!0171.D8FA!0008!FC70.AB27 ``` Edit: Formatting

By Michael Schwartz Account Admin 24 Aug 2016 at 2:30 p.m. CDT

Copy
Michael Schwartz gravatar
oh sorry, `-b` is totally wrong. My fault... that would just look at the `o=gluu` entry...

By Michael Schwartz Account Admin 24 Aug 2016 at 2:37 p.m. CDT

Copy
Michael Schwartz gravatar
I haven't tested this myself, but here's my guess. This Passport strategy is probably using the implicit flow. According to your client registration and code, you are trying to use authorization code flow. See [response_types](http://openid.net/specs/openid-connect-core-1_0.html#Authentication) table in the OpenID Connect spec. Let us know if you can get this working. It would be pretty cool. BTW, in the next version of the Gluu Server we're actually including passport-js as a front-end for social login.

By Chris MacDonald user 24 Aug 2016 at 3:01 p.m. CDT

Copy
Chris MacDonald gravatar
The initial request to the gluu server made by this passport strategy only includes the single response_type (code): ``` https://gluu/oxauth/seam/resource/restv1/oxauth/authorize? response_type=code ``` So it should be doing the Authorization Code Flow. Another thing to note: I can change the passport-openid-connect configuration options below to google's openid connect endpoints, swap the client id/secret and the openid connect authorization works perfectly. ``` authorizationURL: 'https://<gluu-server>/oxauth/seam/resource/restv1/oxauth/authorize', tokenURL: 'https:/<gluu-server>/oxauth/seam/resource/restv1/oxauth/token', userInfoURL: 'https://<gluu-server>/oxauth/seam/resource/restv1/oxauth/userinfo', clientId: <clientId> clientSecret: <clientSecret> ```

By Chris MacDonald user 24 Aug 2016 at 3:48 p.m. CDT

Copy
Chris MacDonald gravatar
Is the problem that I am sending the clientID and clientSecret in the post body instead of an authorization header?

By Michael Schwartz Account Admin 24 Aug 2016 at 3:55 p.m. CDT

Copy
Michael Schwartz gravatar
I assigned the issue to a developer, who hasn't had a time to look at it yet. Please be patient with community support requests.

By Chris MacDonald user 24 Aug 2016 at 3:58 p.m. CDT

Copy
Chris MacDonald gravatar
No problem, thanks for your time so far Mike :) Cheers, Chris

By Yuriy Zabrovarnyy staff 24 Aug 2016 at 4:10 p.m. CDT

Copy
Yuriy Zabrovarnyy gravatar
Exactly, authentication method is set to client_secret_basic which means that client credentials should be encoded in "Authorization" header (which is recommended way to pass client credentials comparing to POST parameters). ``` https://github.com/GluuFederation/oxAuth/blob/30dd412eaf1a8b31049e54677c89c9c0381b848d/Client/src/main/java/org/xdi/oxauth/client/TokenClient.java#L222-222 ``` It should be base64 encoded string : client_id + ":" + client_secret. Here is how it looks in java ``` https://github.com/GluuFederation/oxAuth/blob/f3c9c10a667cda16f7c7995f3540bdc37a42e79a/Client/src/main/java/org/xdi/oxauth/client/BaseRequest.java#L119-119 ``` Let us know whether it help. If no please attache oxauth.log file for investigation. (Make sure log level is set to TRACE, it can be changed in /opt/tomcat/webapps/oxauth/WEB-INF/classes/log4j.xml - tomcat restart required) Thanks, Yuriy Z

By Chris MacDonald user 24 Aug 2016 at 4:23 p.m. CDT

Copy
Chris MacDonald gravatar
Aha! It was a mismatch between how I was sending credentials (client id + secret) and how the configured client was expecting them. In the Web UI it is this: Authentication method for the Token Endpoint In the registration json it is this: token_endpoint_auth_method I modified the client to use client_secret_post instead of client_secret_basic and I was able to get the Access/Refresh tokens. It seems like the npm oauth library that the passport-openid-connect library uses automatically defaults to transfer client credentials using client_basic_post (and does not provide any options to do any other type). The Gluu registration/web client creation defaults to client_secret_basic, which requires the client id/secret to be passed in the authorization header. Perhaps the Gluu server could provide a more direct error message? It could perhaps detect that there are credentials being passed in the incorrect method. Thanks again for your time Mike, and hopefully other people can see this and spend less time than I did. Cheers, Chris

By Chris MacDonald user 24 Aug 2016 at 4:28 p.m. CDT

Copy
Chris MacDonald gravatar
Thanks for taking a look at it Yuriy. It looks like I am stuck using client_secret_post until the issues with the npm oauth library are fixed (or I go and fix them myself to give back to OSS). This is the issue I found for future reference: https://github.com/ciaranj/node-oauth/issues/300 Cheers, Chris

Post an answer