Was the client registered? If so, can you provide the ldif for the client entry from the Gluu OpenDJ server? Also, can you provide the oxAuth logs and ldap logs, or even better the pertinent snippets. Any other info you can provide about the request and responses would be helpful, it's not possible to troubleshoot this without knowing more.

The client is manually registered. How do i make the module request/pass the id_token? I can get the id_token as a query returned if i use ResposeType of id_token. I get back session_id, scope, state and code in URL query that looks like this. http://<mydomain>/redirect/?session_id=993bcd3d-c431-46bc-8045-bae60edf88d4&scope=openid+email+profile&state=7pZmHSjnM-EbcJrEZFR8uZuFot0&code=4bcddcca-b511-4bcc-bb48-b758adeee101 Module configuration looks like so: OIDCRedirectURI http://<mydomain>/redirect OIDCCryptoPassphrase 123456789 OIDCProviderIssuer https://<my domain> OIDCProviderAuthorizationEndpoint https://<my domain>/oxauth/seam/resource/restv1/oxauth/authorize OIDCProviderJwksUri https://<my domain>/oxauth/seam/resource/restv1/oxauth/jwks OIDCProviderTokenEndpoint https://<my domain>/oxauth/seam/resource/restv1/oxauth/token OIDCProviderTokenEndpointAuth client_secret_post OIDCProviderUserInfoEndpoint https://<my domain>/oxauth/seam/resource/restv1/oxauth/userinfo OIDCSSLValidateServer Off OIDCResponseType "code" OIDCClientID @!C032.849B.2FA5.5E8C!0001!BCB6.4A42!0008!D0AC.C912 OIDCClientSecret 123456789123456789123456789 OIDCScope "openid email profile" OIDCOAuthClientID @!C032.849B.2FA5.5E8C!0001!BCB6.4A42!0008!D0AC.C912 OIDCOAuthClientSecret 123456789123456789123456789 OIDCOAuthIntrospectionEndpoint https://<my domain>/oxauth/seam/resource/restv1/introspection OIDCOAuthIntrospectionEndpointMethod POST OIDCOAuthIntrospectionEndpointAuth client_secret_basic OIDCOAuthSSLValidateServer Off <Location /example/> AuthType openid-connect Require valid-user LogLevel debug </Location> <Location /redirect/> AuthType openid-connect #Require valid-user LogLevel debug </Location>

Ok, please provide the ldif: Something like: /opt/opendj/bin/ldapsearch -h localhost -p 1389 -D "cn=directory manager" -w <pass> -b "o=gluu" 'inum=@!C032.849B.2FA5.5E8C!0001!BCB6.4A42!0008!D0AC.C912' This would confirm if you have released the right scopes for this client.

Output from command: /home/gluu-server/opt/opendj/bin/ldapsearch -h localhost -p 1389 -D "cn=directory manager" -w <pass> -b "o=gluu" 'inum=@!C032.849B.2FA5.5E8C!0001!BCB6.4A42!0008!D0AC.C912' Here is the output: dn: inum=@!C032.849B.2FA5.5E8C!0001!BCB6.4A42!0008!D0AC.C912,ou=clients,o=@!C032 .849B.2FA5.5E8C!0001!BCB6.4A42,o=gluu oxAuthScope: inum=@!C032.849B.2FA5.5E8C!0001!BCB6.4A42!0009!764C,ou=scopes,o=@!C 032.849B.2FA5.5E8C!0001!BCB6.4A42,o=gluu oxAuthScope: inum=@!C032.849B.2FA5.5E8C!0001!BCB6.4A42!0009!43F1,ou=scopes,o=@!C 032.849B.2FA5.5E8C!0001!BCB6.4A42,o=gluu oxAuthScope: inum=@!C032.849B.2FA5.5E8C!0001!BCB6.4A42!0009!10B2,ou=scopes,o=@!C 032.849B.2FA5.5E8C!0001!BCB6.4A42,o=gluu oxAuthScope: inum=@!C032.849B.2FA5.5E8C!0001!BCB6.4A42!0009!F0C4,ou=scopes,o=@!C 032.849B.2FA5.5E8C!0001!BCB6.4A42,o=gluu oxAuthScope: inum=@!C032.849B.2FA5.5E8C!0001!BCB6.4A42!0009!3EEA.6E10,ou=scopes, o=@!C032.849B.2FA5.5E8C!0001!BCB6.4A42,o=gluu oxAuthScope: inum=@!C032.849B.2FA5.5E8C!0001!BCB6.4A42!0009!C880.8FB7,ou=scopes, o=@!C032.849B.2FA5.5E8C!0001!BCB6.4A42,o=gluu oxAuthAppType: web oxAuthResponseType: code oxAuthResponseType: token oxAuthResponseType: id_token oxLastAccessTime: 20150512165524.052Z oxAuthClientSecret: HdUJNbcCCEtdTiWp4f7+K7OOlnMbXAfCvaUKC7FCfrM= oxAuthPostLogoutRedirectURI: http://<my domain>/logout objectClass: oxAuthClient objectClass: top oxAuthTokenEndpointAuthMethod: client_secret_post oxAuthRedirectURI: http://<my domain>/codeflow/oauth2callback.php oxAuthRedirectURI: http://<my domain>/implicitflow/oauth2callback.php oxAuthRedirectURI: http://<my domain>/example oxAuthRedirectURI: http://<my domain>/redirect oxLastLogonTime: 20150512145816.430Z oxAuthTrustedClient: true displayName: name123 oxAuthIdTokenSignedResponseAlg: RS256 inum: @!C032.849B.2FA5.5E8C!0001!BCB6.4A42!0008!D0AC.C912

Interesting... it looks like there are some scopes released to this client. The other interesting thing would be to see the HTTP headers. I use a simple python .cgi script for this. Just copy this into the folder, and make sure the folder is configured for cgi in Apache.... ------------------- printHeaders.cgi ------------------- #!/usr/bin/python import os d = os.environ k = d.keys() k.sort() print "Content-type: text/html\n\n" print "<HTML><Head>Print Env Variables</Head><BODY>" print "<h1>Environment Variables</H1>" for item in k: print "<p><B>%s</B>: %s </p>" % (item, d[item]) print "</BODY></HTML>"

I used the python script as the redirect URI and below is the output: Print Env Variables Environment Variables CONTEXT_DOCUMENT_ROOT: /var/www/cgi-bin/ CONTEXT_PREFIX: /cgi-bin/ DOCUMENT_ROOT: /var/www/html GATEWAY_INTERFACE: CGI/1.1 HTTP_ACCEPT: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 HTTP_ACCEPT_ENCODING: gzip, deflate HTTP_ACCEPT_LANGUAGE: en-US,en;q=0.5 HTTP_CONNECTION: keep-alive HTTP_COOKIE: PHPSESSID=i90q4fhpnj1uq6d6oea7r9n1o3; mod_auth_openidc_state_0XSmou_C22Ho9uPZQXY4fPExJSg=oEhO0m3NiVB--8NMS-pSix4sjS9vMYGOXxnkQtMJLDn99Tfb7mYKAarmF_MiKs2E7BKQzVhMh5A5qtART7BkPj8XcIUQCpXu_kJebskJV9_Tt1OLfk7P-3v_KeEI0FDHMYhsI3LLwEWXxt4CqFaFzdx2nfZO4iACOWb_x5RhcVh-1fMkdoryei5N0qd3d8tHTRYPdRKYdWAUPjqyJgqP6yfTusTsA6LBmlRH6_J1CWw82sFpJcVRf4o-CKsMiFy66lCnsYXSF3GD3buRJrUrhgDbB4i6SrJfsnx4l4Gh330 HTTP_HOST: <my domain> HTTP_USER_AGENT: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 PATH: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QUERY_STRING: session_id=993bcd3d-c431-46bc-8045-bae60edf88d4&scope=openid+email+profile&state=0XSmou_C22Ho9uPZQXY4fPExJSg&code=1ad9bedd-f65a-48e7-a0fa-6385d27586f8 REMOTE_ADDR: 172.16.4.103 REMOTE_PORT: 37317 REQUEST_METHOD: GET REQUEST_SCHEME: http REQUEST_URI: /cgi-bin/printheaders.py?session_id=993bcd3d-c431-46bc-8045-bae60edf88d4&scope=openid+email+profile&state=0XSmou_C22Ho9uPZQXY4fPExJSg&code=1ad9bedd-f65a-48e7-a0fa-6385d27586f8 SCRIPT_FILENAME: /var/www/cgi-bin/printheaders.py SCRIPT_NAME: /cgi-bin/printheaders.py SERVER_ADDR: <my domain> SERVER_ADMIN: root@localhost SERVER_NAME: <my domain> SERVER_PORT: 80 SERVER_PROTOCOL: HTTP/1.1 SERVER_SIGNATURE: SERVER_SOFTWARE: Apache/2.4.6 (Red Hat) PHP/5.4.16 UNIQUE_ID: VVJZNdAytZwNGQ6rhPwXhQAAAAE

One thing that's a little weird... you are using HTTP? I trust model requires HTTPS, otherwise the tokens would leak. SSL cert verfication is optional, but not HTTPS...

In this example i am. I enabled HTTPS with a self signed cert. In addition of few SSL fields the header looks the same. Am i correct in understanding that the code that's returned in the URL QUERY should be used to request an id_token by the module? And the token is returned in the header. And that all of that should be happening automatically. As things are now i can see the code in the query but am not getting anything else.

Then why are all the redirects http? oxAuthRedirectURI: http://<my domain>/codeflow/oauth2callback.php oxAuthRedirectURI: http://<my domain>/implicitflow/oauth2callback.php oxAuthRedirectURI: http://<my domain>/example oxAuthRedirectURI: http://<my domain>/redirect It may be wise to use the dynamic client registration built into mod_auth_openidc instead of adding your own client manually...

I have since corrected that and now am using https. I have used the http://&lt;my domain&gt;/implicitflow/oauth2callback.php and fallowed the implicit implementation and i can use that to receive the tokens. For our application we will not need dynamic registration at the moment and i thought it would be easier to do a manual registration to get things moving. I can also use server side scripting language (for basic client implementation) to request tokens from the token endpoint using the code and that is what the http://&lt;my domain&gt;/codeflow/oauth2callback.php redirect was for. Can't get the module to return the tokens unless i set OIDCResponseType to id_token. Thanks

I assigned this issue to Anik, one of the engineers. He is going to see if he can replicate the configuration and write an article about it.

Hello, I had a chat with Hans earlier today about this issue and he suggested to use that code grant in a backchannel call to the OP to get the id_token and access_token and supply the resulting claims as HTTP header values to the application. If the issue still persists, please turn up the LogLevel and provide the logs here. I will show him the logs and see if we can identify the root cause of the issue from there. Thanks.