empty client_secret leads to "Missing credentials" error while request POST oauth/token

[martinsubash]

SECURITY NOTICE: If you have found a security problem in the UAA, please do not file a public github issue. Instead, please send an email to security@cloudfoundry.org

Thanks for taking the time to file an issue. You'll minimize back and forth and help us help you more effectively by answering all of the following questions as specifically and completely as you can.

What version of UAA are you running?

76.31.0

How are you deploying the UAA?

I am deploying the UAA

• locally only using gradlew
• using a bosh release I downloaded from bosh.io
• using cf-release
• using cf-deployment
• as part of a commercial Cloud Foundry distribution

What did you do?

I am trying to upgrade UAA 76.11.0 to 76.31.0.

During login, the POST oauth/token request with empty secret client_secret: leads the below error.

Request: POST http://access.localhost:8080/uaa/oauth/token
Payload:
grant_type: authorization_code
code: xxxxxxxxxxxxxx
redirect_uri: http://localhost:8084/accessapp/index.html
code_verifier: xxxxxxxxxxxxxxxxxxxxxxxx
client_id: access-blueprint
client_secret:

Response Code: 401 Unauthorized {"error":"invalid_client","error_description":"Missing credentials"}

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

The POST http://access.localhost:8080/uaa/oauth/token request should be return token

What did you see instead?

The POST http://access.localhost:8080/uaa/oauth/token responded with 401 Unauthorized {"error":"invalid_client","error_description":"Missing credentials"}

Is UAA 76.31.0 not support empty secret? is it mandatory to having some secrets? UAA 76.11.0 secret is not mandatory for clients, Is there any guidelines or policy to not allowing empty secret?

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/187143951

The labels on this github issue will be updated when the story is started.

[strehle]

Hi,

see here. empty secrets are now forbidden, but if you want use them, you have to define them in your client definition.
See
https://github.com/cloudfoundry/uaa/releases/tag/v76.24.0
#2574

The fallback from nothing to empty secret is a security issue.

However, if you simply want use your UAA , then set
client_secret: ""

The other way to support them is allowpublic
https://docs.cloudfoundry.org/api/uaa/version/77.1.0/index.html#update-4
Then your client needs to be aware of the authorization code flow without secrets. This means you need to support PKCE

[martinsubash]

@strehle Thank you for the details.
In my case setting the client_secret: "" in my seed file working for the new clients.
But, lot of existing identity zones clients not working since they are created already with empty client_secret.
How can I migrate the existing clients? or How can I resolve this issue for existing/already created clients?

[strehle]

@strehle Thank you for the details. In my case setting the client_secret: "" in my seed file working for the new clients. But, lot of existing identity zones clients not working since they are created already with empty client_secret. How can I migrate the existing clients? or How can I resolve this issue for existing/already created clients?

I have not verified it, but I am sure that existing clients should have "" as secret.

[martinsubash]

@strehle In my application code now I set the client secret ="", so the newly created client(yellow marked one) has encoded text in the DB for client_secret column, and it authenticated as expected. But the existing clients that have null client_secret are not authenticated.

Shall I update this randomly generated encoded text to the other clients that have null values? or is there any other way to update the null-valued clients?

see the attachment here.

[strehle]

The secret value is a bcryt so please dont share other values from your DB.
However, the fact that you have many clients with same client_id means they are in different zones ?

Via uaa.yaml you cannot provision this.

Recommendation is: please define a good secret or omit it (null, like your case). Because if you dont want care for secrets, then you can use public flow.
But if you want simply restore what you had, then you need to set "", yes.

[strehle]

I assume this can be closed now ?