Client creation endpoint does not accept two secrets to support rotation

In the UAA API Documentation for Client Create endpoint, it is mentioned that two secrets can be used (delimited with a space) for a single client.

client_secret - A secret string used for authenticating as this client. To support secret rotation this can be space delimited string of two secrets.

However if two secrets, delimited with space character are used, the UAA does not split them and neither of them works.

What version of UAA are you running?

What output do you see from curl <YOUR_UAA>/info -H'Accept: application/json'?

{
  "app": {
    "version": "v75.5.0"
  }
  ...
}

How are you deploying the UAA?

I am deploying the UAA

• locally only using gradlew

What did you do?

Create client with two secrets delimited with a space character:

 curl 'http://localhost/oauth/clients' -i -X POST \
    -H 'Content-Type: application/json' \
    -H 'Authorization: Bearer 3c44a1c0c4744d8996de460077ed37e2' \
    -H 'Accept: application/json' \
    -d '{
  "scope" : [ "clients.read", "clients.write" ],
  "client_id" : "NWDGM7",
  "client_secret" : "secret1 secret2",
  "resource_ids" : [ ],
  "authorized_grant_types" : [ "client_credentials" ],
  "redirect_uri" : [ "http://test1.com", "http://ant.path.wildcard/**/passback/*" ],
  "authorities" : [ "clients.read", "clients.write" ],
  "token_salt" : "3qJVLu",
  "autoapprove" : true,
  "allowedproviders" : [ "uaa", "ldap", "my-saml-provider" ],
  "name" : "My Client Name"
}'

Try to obtain token using secret1 or secret2. Both will fail with error:

{
    "error": "unauthorized",
    "error_description": "Bad credentials"
}

However if secret secret1 secret2 is used the authorization succeeds.

What did you expect to see? What goal are you trying to achieve with the UAA?

I expected to be able to obtain token using both secrets: secret1 or secret2.

What did you see instead?

{
    "error": "unauthorized",
    "error_description": "Bad credentials"
}

Please include UAA logs if available.

[UAA_AUDIT] [2021-08-05T06:54:34.669545Z] uaa - 1 [http-nio-8080-exec-9] ....  INFO --- Audit: PrincipalAuthenticationFailure ('null'): principal=NWDGM7, origin=[192.168.65.3], identityZoneId=[xxx]
[UAA] [2021-08-05T06:54:34.669545Z] uaa - 1 [http-nio-8080-exec-9] ....  INFO --- Audit: PrincipalAuthenticationFailure ('null'): principal=NWDGM7, origin=[192.168.65.3], identityZoneId=[xxx]
[UAA_AUDIT] [2021-08-05T06:54:34.670204Z] uaa - 1 [http-nio-8080-exec-9] ....  INFO --- Audit: ClientAuthenticationFailure ('Bad credentials'): principal=NWDGM7, origin=[remoteAddress=192.168.65.3, clientId=NWDGM7], identityZoneId=[xxx]
[UAA] [2021-08-05T06:54:34.670204Z] uaa - 1 [http-nio-8080-exec-9] ....  INFO --- Audit: ClientAuthenticationFailure ('Bad credentials'): principal=NWDGM7, origin=[remoteAddress=192.168.65.3, clientId=NWDGM7], identityZoneId=[xxx]

[tkurylek]

Hi @strehle

Thanks a lot for the suggestions. I’m open to create a PR for that.

I understand that fixing this issue on client creation endpoint would break the compatibility and thus there should be an extra parameter. Could you suggest any approach to this? I was thinking about:

• adding a header that would work as a feature flag to split the given secrets. if the header is missing the creation would work as before
• adding a parameter to the uaa.yaml. if that parameter is set to true then we would split the secrets on client creation endpoint, if not – it would be working as before
• extending org.springframework.security.oauth2.provider.ClientDetails to support another json property (e.g. “secondary_client_secret”) and accepting it in the client creation endpoint:

@RequestMapping(value = "/oauth/clients", method = RequestMethod.POST)
// ...
public ClientDetails createClientDetails(@RequestBody ClientDetailsCreation client) {
  // ...
}

Thank you for suggesting mixed actions endpoint. Unfortunately the Mixed Actions endpoint does not support an action to ADD a secret. I would like to create a client with two secrets so I tried:

[
	{
		"action": "add",
		"scope": [
			"openid"
		],
		"client_secret": "secret1",
		"client_id": "client_id",
 "//": "(... other client details properties ...)"
	},
	{
		"action": "secret",
		"client_secret": "secret2",
		"client_id": "client_id"
	}
]

But that updates the secret1 to secret2 and only secret2 is working. This endpoint would have to support another action, like “add_secret” which would make both secrets working.

In the end I have two options – both would work for us. I could:

• fix the issue in client creation endpoint
• add new action (“add_secret”) to the mixed actions endpoint.

I would greatly appreciate your input here.

[tkurylek]

Hi @strehle

This is how we currently work around this issue. But it would be better if there would be a possibility to create a client with two secrets via a single HTTP call. This would make the client creation transactional. With two HTTP calls it’s very problematic to ensure data consistency.