Limiting Scopes for client resources

[robatsu]

For some business logic reasons, we are going to have a SCOPE_VERIFY distinct from the usual SCOPE_READ/WRITE, etc.

We want it such that this scope has to be alone in a request for an authorization code, can't be combined with other scopes.

This will force clients to define at least two client resources in their config, one with all their other authorized grant types and one with only SCOPE_VERIFY.

I'm trying to figure out the best way on the provider end to enforce this restriction, but haven't quite come up with something that doesn't seem hacky/kludgy. So I'm wondering what would be right and proper way to:

1) Never grant an access token (via authorization_code) w/verify combined w/any other scope.
2) Never allow a client w/any scope other than verify to access resources that are SCOPE_VERIFY

Thanks!

Jay Roberts

[robatsu]

Hmm, looks like maybe my own subclass of AuthorizationEndpoint is necessary.

[Dave Syer]

Maybe I'm not understanding your use case in enough detail, but a) it doesn't seem like a problem for the authorization server at all (protecting resources is the resource server's responsibility), b) if you did need to change the token granting behaviour I would hope that you could inject a TokenGranter into the existing AuthorizationEndpoint.

If I understod correctly, what I would do is register 2 clients, one which can only get scope=verify, and one that has the other scopes.

If you want to keep it to a single client and make changes only in the resource server, you could use SpEL expressions in the resource <intercept-url/> elements, and use the oauthHasScope('verify') in one resource and oauthHasAnyScope('read', 'write') etc. for the other.