users@jax-rs-spec.java.net

[jax-rs-spec users] [jsr339-experts] Re: offtopic: Java EE Security media type

From: Sergey Beryozkin <sberyozkin_at_talend.com>
Date: Thu, 18 Oct 2012 16:18:09 +0100

Hi Bill,
On 18/10/12 14:20, Bill Burke wrote:
>
>
> On 10/18/2012 5:19 AM, Sergey Beryozkin wrote:
>> On 18/10/12 00:01, Bill Burke wrote:
>>> Thats the thing. AFAICT, OAuth2 leaves the token format undefined. SAML
>>> has a mapping, but it would be cool to have a Java EE specific token
>>> format.
>>
>> using Java EE to implement OAuth2 is an implementation detail, so I'm
>> not sure there's any scope for getting something JavaEE specific into
>> the protocol
>>
>
> Its not an implementation detail because OAuth2 does not define a token
> format AFAICT.
>
> something like this:
>
> {
> "user" : "bill"
> "roles" : [ "admin" ]
> "permissions" : "blah"
> }
>
> There's no interoperability in OAuth 2 because the token format is
> undefined. I'm just saying define a token format for Java EE and any
> OAuth2 extensions we might perceive a need for.
>

AFAIK, the info like this is not supposed to get back to 3rd party
client in a clear form. JWT and SAML (OAuth2) tokens address it with the
use of claims - I think they only start making sense when we have
identity providers involved. In a simple 'bearer' case this info is
supposed to be retrieved on the server, or in advanced cases, one can
imagine encrypting this info.
Besides, an info like you typed above would not be of interest to Java
servers only hence I was implying that was an impl detail.

One can certainly come with the above format too -- if that proves to be
of interest


>>>
>>> There does seem to be a registry defined in the OAuth2 RFC.
>>>
>>> FYI, Eran Hammer, the previous lead, quit OAuth2 and ranted like crazy:
>>>
>>> http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/
>>>
>>
>> Does not mean OAuth2 is totally broken
>>
>
> I like that they left the token format open. At first glance they also
> made the protocol very browser centric.

They have few flows with no user involved. As for the mainstream flow,
the browser is assumed but I guess is not strictly required, as far as
the interaction with the user and support for the redirections are concerned

Cheers, Sergey