[jax-rs-spec users] Re: JAX-RS Security

From: Sergey Beryozkin <>
Date: Wed, 17 Dec 2014 14:27:59 +0000

On 17/12/14 14:09, Bill Burke wrote:
> 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
>> 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.
I think having something like @Scopes and enforce a scope based AC is
interesting as it can offer a more involved AC compared to @RolesAllowed.

one can map a token to a list of scopes.
However it is probably unlikely it will make it into JAX-RS though...
That said I'll think of doing something like that in CXF, if I do then I
will publicly acknowledge it was Casey's idea


> [1]