This error is retuned when oxd 3.1.4 can't find setup client for given RP https://github.com/GluuFederation/oxd/blob/f7b1b14c9566d43aa68f539a411ca3b3b9d9c93a/oxd-server/src/main/java/org/xdi/oxd/server/service/ValidationService.java#L129 I believe you are using wrong `oxd_id`. On `setup_client` command as response you get 2 ids `oxd_id` and `setup_client_oxd_id`. Make sure for all further calls you are using `oxd_id` and not `setup_client_oxd_id`. I know it's confusing. In future version we dropped this 2 client's concept. Thanks, Yuriy Z

Hi Yuriy, thanks for getting back to me. I'm going to double-check, but I did see the comment about being careful of using the correct oxd_id, and so I tried with both (just in case). Let me revisit so I can be 100% certain.

OK, I see that the `client_secret` provided in the `setup_client` response is for the `setup_client_oxd_id`, and so I needed to get the correct one from the Gluu admin UI - does that sound right? Using these credentials I do make progress, but still fall short of success. The AS seems to be happy: > 2019-02-13 09:54:47,886 INFO [qtp804611486-15] [org.xdi.oxauth.auth.Authenticator] (Authenticator.java:224) - Authentication success for Client: '@!3932.OBFUSCATE-FOR-TICKET' However the oxd-server seems to receive a null access_token from the AS: > 2019-02-13 09:54:47,891 ERROR [org.xdi.oxd.server.op.GetClientTokenOperation] access_token is blank in response, params: GetClientTokenParams{clientId='@!3932.OBFUSCATE-FOR-TICKET', opHost='https://as.example.com', opDiscoveryPath='null', scope=[openid, profile, email, uma_protection, oxd], authenticationMethod='null', algorithm='null', keyId='null'}, response: org.xdi.oxauth.client.TokenResponse@27dd1f > 2019-02-13 09:54:47,891 ERROR [org.xdi.oxd.server.op.GetClientTokenOperation] Please check AS logs for more details (oxauth.log for CE). > 2019-02-13 09:54:47,908 TRACE [org.xdi.oxd.server.Processor] Send back response: {"status":"error","data":{"error":"internal_error","details":null,"error_description":"Unknown internal server error occurs."}} > 2019-02-13 09:54:47,908 ERROR [org.xdi.oxd.server.SocketProcessor] Quit. Enable to process command. The final message appears to be fatal, as while oxd-server is still running, it won't respond to any further commands with anything other than `null`. A restart resolves that. Why would the AS return a null access_token?

Yes, to obtain protection access token you have to use setup client. It looks correct. The reason why it may return null is some type of mis-configuration of your client or otherwise AS. First thing I would check is whether your `clientId='@!3932.OBFUSCATE-FOR-TICKET'` have `grant_type=client_credentials` and scopes `oxd` and `uma_protection`. Check it directly in LDAP. If it's there then there must be some error in `oxauth.log`. Make sure you have log level `TRACE`. If you didn't find anything then send me `oxauth.log` and LDIF of your `clientId='@!3932.OBFUSCATE-FOR-TICKET'`. Thanks, Yuriy Z

Ahha, yes, that's it. Looks like the dynamically generated `oxd_id` client did not have the `client_credentials` grant_type (though the client with `setup_client_oxd_id` did have this). I used the defaults assuming as per the docs. Given that it's required for a functional setup, maybe we can update the defaults to include this otherwise the JSON payload probably needs to have that field set as "Required"? I've hit another error, but I'll try and see to that and let you know if I face any more issues. Thanks again!

`client_credentials` grant type is added automatically for `setup_client`. Unless/otherwise you modified it. `oxd_id` is for regular use, not for obtaining protection access token. Anyway, glad to hear it works for you finally. Can we close this ticket ? Feel free to raise new ticket for new problem. Thanks, Yuriy Z

Hi Yuriy, Thanks again for the quick response. I've been scratching my head quite a bit with this one. Can you help explain what you mean by "regular use". I understand that you have done away with two clients, but as (at least from what I can see) the concept is unique to Gluu, I'm struggling to delineate "regular" from "irregular". Do you mean that RS resource protection and general setup of an RS is done by the setup_client, or is it only setup of OXD?! Here's my confused face: O_o?

We have detailed explanation of those 2 clients in our docs here: https://gluu.org/docs/oxd/3.1.4/api/#set-up-client If you will have questions to that, please let me know. I will try to explain and correct also docs, so it's clear to everyone. > Do you mean that RS resource protection and general setup of an RS is done by the setup_client No, as said in docs, setup client is only to obtain `protection_access_token`, nothing else. Then use `oxd_id` (not setup client) for all operations, inclusing RS resource protection. Thanks, Yuriy Z

OK, many thanks. Can I suggest a change to the guide? Probably something that emphasizes the one-off nature of client 1: client 1 - (or "setup client") used solely for communication protection. This will only be used to obtain an access token via the Get Client Token command. The access token will be passed as a protection_access_token parameter to other commands using client 2. uma_protection scope must be present in the request to the setup_client command. Relating fields in the response to this client: - setup_client_oxd_id: oxd_id of this setup client - client_id: client id of this setup client - client_secret: client secret of this setup client client 2 - a client which can be used for all **other** oxd operations. Identified in the response as `oxd_id`. NB: This second client will be removed from future registration responses, and users of the API should instead utilize the register_site command to access the `oxd_id` of the client for regular use.

We will improve docs, thanks for feedback! https://github.com/GluuFederation/docs-oxd-prod/issues/41 Thanks, Yuriy Z