The request to /oauth/authorize takes in a scope parameter where you can
specify which scopes you want in your access token. That is what adding the
scope in application.yml did. If you don't specify any scope parameter to
that request you get all the scopes that both the client and user have in
common. So in your case,

http://localhost:8080/uaa/oauth/authorize?client_id=myApp&redirect_uri=http://localhost:8081/login&response_type=code&scope=uaa.admin%20openid&state=QUHpO2

and

http://localhost:8080/uaa/oauth/authorize?client_id=myApp&redirect_uri=http://localhost:8081/login&response_type=code&state=QUHpO2
<http://localhost:8080/uaa/oauth/authorize?client_id=myApp&redirect_uri=http://localhost:8081/login&response_type=code&scope=uaa.admin%20openid&state=QUHpO2>


will end up with the same result.

The reason why uaa.admin does not show up on the authorization page in both
cases is because the UAA ignores scopes with a prefix of `uaa.` when asking
the user to authorize the scopes.

On Wed, Jun 29, 2016 at 3:04 PM, Bryan Perino <Bryan.Perino(a)gmail.com>
wrote:

Thanks! I am not sure if it makes a difference, but I can also specify the
scope in the client config:


https://gist.github.com/bryantp/4b3dadb17c620d301109859fd92c4539#file-application-yml-L16

The request URL then becomes:


http://localhost:8080/uaa/oauth/authorize?client_id=myApp&redirect_uri=http://localhost:8081/login&response_type=code&scope=uaa.admin%20openid&state=QUHpO2

Full HAR file:

https://dl.dropboxusercontent.com/u/4177525/request-with-scopes.har

However, I still only get the OpenID auth/scope on the UAA auth page.