Hi, Andy. `mod_auth_openidc` have been working great with Gluu for a long time. Your issue most likely is due to some miss-configuration. For now it's not perfectly clear on what OIDC phase you are getting this error. Please check logs inside of the container (including Apache's access log, as it will be containing initial request to Gluu's OIDC authz endpoint, with all parameters used in it) and provide fragments related to your issue here.

Aliaksandr - looking in error.log this is what i get: ``` [Mon Dec 12 17:27:09.567566 2016] [auth_openidc:error] [pid 2979:tid 139887755884288] [client 82.15.250.246:54310] oidc_ut il_json_string_print: oidc_util_check_json_error: response contained an "error" entry with value: ""invalid_request"" [Mon Dec 12 17:27:09.567935 2016] [auth_openidc:error] [pid 2979:tid 139887755884288] [client 82.15.250.246:54310] oidc_ut il_json_string_print: oidc_util_check_json_error: response contained an "error_description" entry with value: ""The reques t is missing a required parameter, includes an unsupported parameter or parameter value, repeats a parameter, includes mul tiple credentials, utilizes more than one mechanism for authenticating the client, or is otherwise malformed."" ``` What i am attempting is to use a token obtained from https://gluu.iolab.uk, to authorize access to my endpoint which is on a test azure server (which has openidc). I am making a request to the resource, /secure with Postman, including the Access Token using a bearer type. I am sure i am doing something simply wrong here - just very little documentation around on resource servers using Gluu and mod_auth_openidc

Did you check the HOWTO document: [https://gluu.org/docs/integrate/centos-installation/](https://gluu.org/docs/integrate/centos-installation/) The best thing is to allow it to do dynamic client registration, and then see what files it creates. Then move for manual configuration.

Thanks, Andy, still it's not enough. What I had in mind is logs in the Gluu's container (it also uses Apache as front-end web server). Checking the situation at one side of connection won't help much. More about logs [here](https://gluu.org/docs/reference/logs/) In addition, please run this inside of container to dump configuration for your client (I take it your current client's id is `@!3F75.CB71.5014.7270!0001!5D85.448C!0008!06E9.0F43`): ``` # 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=@!3F75.CB71.5014.7270!0001!5D85.448C!0008!06E9.0F43'` # rm ~/.pw ``` `YOUR_LDAP_PASS` should be the same as you default admin password.

Mike - i did, i am probably misunderstanding... I dont actually want to initiate the auth flow from the resource server - i think i am actually trying to do what is documented here: https://github.com/pingidentity/mod_auth_openidc/wiki/OAuth-2.0-Resource-Server

We haven't tested that use case. What policies do you want to tie to the issuance of this token? If the policies involve something more than user approval, you should maybe consider UMA. Gluu has an API gateway that leverages the oxd client software which can act as a web policy enforcement point, but it uses UMA tokens rather then OpenID Connect tokens. See [https://github.com/GluuFederation/kong-plugins/tree/master/kong-uma-rs](https://github.com/GluuFederation/kong-plugins/tree/master/kong-uma-rs) If you want to discuss this, please setup a meeting on [http://gluu.org/booking](http://gluu.org/booking)

Hi, Andy. Do we need to keep this ticket open? Do you still have some questions left?