[security-dev] Resteasy 3.0-beta-2 released with OAuth2 support
bburke at redhat.com
Wed Feb 20 08:34:08 EST 2013
On 2/19/2013 9:05 PM, Anil Saldhana wrote:
> On 02/19/2013 11:36 AM, Bill Burke wrote:
>> I don't have support for:
>> * Implicit
>> * Resource Owner Password Credentials Grant
>> It only supports Access Code and Client Credentials Grants. For good
>> "Implicit" is an optimization for *public*, insecure clients and not a
>> protocol that should be promoted or supported by Resteasy or Picketlink,
> I am unsure if "implicit" usecase implies insecure. All it does is
> avoids the intermediate
from using the Access Code protocol. Also "Implicit" explicitly states
that it is an optimization for public clients. It is very insecure
because it does not require authentication of the client.
>> The Resteasy's "Client Credentials Grant" generates a token for *ANY*
>> authenticated user, be it client or resource owner. So, it could take
>> the place of "Resource Owner Password Credentials Grant". I could
>> implement the "Resource Owner Password Credentials Grant" protocol very
>> easily if required, but I just don't see the need for it right now.
> It is typically used by mobile apps. Doing OAuth style interaction in
> native apps is just crazy.
> I do not think it is useful for server side hosted apps.
I don't agree with your "crazy" assessment.
#1 Mobile clients can just use "Client Credentials Grant" with Resteasy
to obtain a token. This is one HTTP request to the auth server.
#2, Access Code for native app is not *crazy* it is just one extra HTTP
request compared to Implicit, as most of the redirects are local (at
least for iPhone, not sure about Android)
Please feel free to argue as I'd like to be proven wrong so I can
correct any problems in our oauth implementation.
JBoss, a division of Red Hat
More information about the security-dev