On 12/16/2014 7:58 PM, Casey Lee wrote:
> Yes, works fine on client side...ends up being rather abstract with
> properties and I'd prefer to see auth more prominent. Either way, not
> a big issue...I yield on the client side.
>
> As for server side, I'd still prefer to see something more declarative
> on the resources. Specifically, I'd like to see something that deals
> with the multiple parties involved with OAuth 2.0. Now maybe the
> answer is "We don't want to have anything OAuth related in the API".
> If that isn't the case, then it seems there ought to be two types of
> annotations...one for permitting roles that the resource owner is in,
> and the other for permitting roles from the scopes on the token.
>
OAuth 2 token formats are completely opaque and dependent on the vendor
implementation. OAuth 2 doesn't define anything about
permissions/roles. Neither does OpenID Connect. OIDC scopes are more
about which claims the OIDC client wants in the IDToken.
That being said, for our security solution [1] our tokens are built
individually for each client and populated with the intersection of the
user's role mappings and the client's allowed scope. So there's no need
for a service to distinguish between user role mappings and client
scope, the service just deals with @RolesAllowed.
[1]
http://keycloak.org
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com