Hi, Dan. Have you tried restarting oxAuth (usually is not required in this case, but worth a try)? If this won't help, could you provide LDIF dump of this client? 1. In web UI go to "OpenID Connect -> Clients" 2. Get "Inum" value of client in question 3. Put your LDAP password (same as default admin pass) inside `/tmp/.pw` 4. Run this command in the container: `# ldapsearch -p 1636 -s sub -T -Z -X -D 'cn=directory manager,o=gluu' -j '/tmp/.pw' -b 'o=gluu' '&(objectclass=oxauthclient)(inum=@YOUR_CLIENTS_INUM)'` You may want to remove a password from the output before sharing it.

Hi, Yes I've tried restarting the server but it still returns the token as a JWT. I'm attaching the output of the ldapsearch command above. Dan

Hi, Dan. My apologies, that seems to be an issue with web UI. I created [github report](https://github.com/GluuFederation/oxTrust/issues/745) so it could be fixed. The problem is that it's impossible to restore original, empty state of the property via web UI, and "none" value is not exactly the same as empty state as well (it just returns an unsigned JWT if set to the latter). For now, please follow next steps to reset it: 1. In web UI go to "OpenID Connect -> Clients" 2. Get "Inum" value of client in question 3. Put your LDAP password (same as default admin pass) inside `/tmp/.pw` 4. Run this command in the container to learn full DN of this client's LDAP entry: `# ldapsearch -p 1636 -s sub -T -Z -X -D 'cn=directory manager,o=gluu' -j '/tmp/.pw' -b 'o=gluu' '&(objectclass=oxauthclient)(inum=@YOUR_CLIENTS_INUM)'` 5. Create `~/set_client_attr.ldif` file with contents provided below, using the DN you've learned before instead of bogus one used by me: ``` dn: inum=@!XXXX.XXXX.XXXX.XXXX!0001!XXX.255C!0008!25E1.76B4.6551.D42C,ou=clients,o=@!XXXX.XXXX.XXXX.XXXX!0001!B977.255C,o=gluu changetype: modify delete: oxAuthSignedResponseAlg ``` Now run next command to apply the change: `# ldapmodify -p 1636 -Z -X -D 'cn=directory manager,o=gluu' -j '/tmp/.pw' -f ~/set_client_attr.ldif`

That seems to have done the trick. Thanks very much!

I'm not familiar with ldap management and these tools (ldapsearch, modify add etc...). Are they the recommended tools to use to migrate client configuration from environment to environment (i.e. from dev -> test -> prod) or is there a different accepted workflow to achieve this? (I can log the question separately if you prefer)

Hi, Dan. Glad to know it helped, you're welcome. >(I can log the question separately if you prefer) If you feel that may become a separate - and sizeable - project, that would be better, indeed. If you just would like to clarify a couple of things, we could continue here, no problem. >I'm not familiar with ldap management and these tools (ldapsearch, modify add etc...). Are they the recommended tools to use to migrate client configuration from environment to environment (i.e. from dev -> test -> prod) or is there a different accepted workflow to achieve this? I wouldn't say "recommended", as it sounds too restrictive, let's say it's probably the easiest, "pre-packaged" method of dumping some items from Gluu's LDAP server, and re-importing them back to it, or some other server. LDAP is established and well-defined protocol, so, if need will arise, you can use any other tool which meets your requirement. Like, you could produce a Python script which could automate such imports to a lot of servers at once. For quick and easy edits I also like to use **Jxplorer** GUI tool, though it doesn't scale well, and for batch jobs console tools are suited better. So, anything that can communicate with Gluu via LDAP is fine. Using some other ways (non-LDAP ways) is what probably not recommended (like, any kinds of direct edits to database files etc). Another solid option would be, of course, simply using web UI to re-create client registration with the same properties at the other server, though it doesn't scale at all and may be frustrating if you have to do this often :) Writing some kind of script (python, bash etc) that automates it would be more practical in such case. Specifically for case of OIDC clients you may also consider [Dynamic client registration flow](https://openid.net/specs/openid-connect-registration-1_0.html) You just need to be aware, that unless you specifically designed all said servers to be exactly the same in terms of LDAP server's contents, you can't just dump some configuration item from one Gluu instance, and import it to another. As you've already perhaps noted when doing searches and edits before, there is a lot of uniqueness in different attributes of those entries. Each server is assigned a couple of unique tokens upon its initialization, which then end up in its DNs and attributes' values. You'll need to pre-process dumped items so they would become compatible with another server's directory tree, in such case.

Thanks for the clarifications. I had noticed the various unique inums etc... and figured there could be some complexities to just dumping from one server and loading to another.