Hi Matt,

Having auto approve true on a client means the token will be granted without the user having to approve the scopes that the client is requesting. It is used for clients that have a grant type of "implicit" or "authorization_code". The grant type decides whether you have a response_type=token or a response_type=code (implicit being the grant type that can be used to get the token directly) in the request to /oauth/authorize.

The cf client is a client of type "password grant" which does not require approval of scopes by the user.

https://github.com/cloudfoundry/uaa-release/blob/develop/jobs/uaa/spec#L229 This property is being deprecated because auto-approve can be specified under the uaa.clients section on a per client basis.

Madhura

On Jan 21, 2016, at 1:07 PM, Matt Cholick <cholick(a)gmail.com> wrote:

We recently upgrades from 222 to 228 and saw a change we'd like to know the reason for.

Looking at the generated uaa.yml for the job's config, in the newest version, oauth.client.autoapprove only contains "login" and "support-signon". If we look back to the file in our other environments (still 222), the list also contains "cf". The shorter list looks to be what uaa-release has had for a while, so I'm guessing in the older environments the larger list is merged from elsewhere (I didn't find the source for this default value including "cf" in 222)

What was the reason for this change?

We're using the flow Trusted Authentication from Login Server
https://github.com/cloudfoundry/uaa/blob/master/docs/UAA-APIs.rst#trusted-authentication-from-login-server
And having auto-approve means that in step 1, we can ask for response_type=token rather than response_type=code to immediately get the token.

Also, this property is listed as deprecated:
https://github.com/cloudfoundry/uaa-release/blob/develop/jobs/uaa/spec#L229
We're relying on it in our login server. When is the uaa team planning to remove it?

-Matt Cholick