Support for requesting different scopes on tokens via the CLI

[jsorah]

Currently the CLI tool only statically requests the scope openid.

As a user/integrator of a client to Keycloak, it would be useful to request different scopes available to my client.

There are certainly a number of ways this could be handled, though I am not familiar enough with picocli to know the spectrum of different ways this could be done within that framework.

1. Having a "scope" flag defined multiple times

   kc-cli token -s openid -s another-scope -s another-scope2

Which would result in a scope value of openid another-scope another-scope2

2. Having the user just specify the scope string via the scope flag with quotes

   kc-cli token -s "openid another-scope another-scope2"

3. Having the user just specify the scope string via the scope flag without quotes

   kc-cli token -s openid another-scope another-scope2

EDIT: Looks like with picocli if you set arity to 0..* you can basically have all three behaviors I mentioned, and you just need to do some normalization of the scope value before passing it around. Might be good for a domain class too? Maybe some kind of RequestedScope class so you don't just have some string arg floating around and that could also encapsulate the normalization strategy logic?

Some Other Considerations

• Given this is an OIDC client, should openid just be in the scope list by default and users can turn this behavior off?
• Should the CLI persist the last requested scope along with any token stored, such that it could do a comparison to that scope list and request a net-new token if required?
  • This would be needed since Keycloak allows users to hide scopes on the access token and one couldn't rely on inspecting the scope value received in the token alone.

[stianst]

Planning on incorporating this. The idea is to have a context configured with a scope, but then you can obtain a token with a subset of those scopes. Also thinking about allowing multiple contexts be able to have a parent context, that would allow having a single login/refresh token, while obtaining access tokens for distinct use-cases.