Re: [security-dev] Resteasy 3.0-beta-2 released with OAuth2 support
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
> reason...
>
> "Implicit" is an optimization for *public*, insecure clients and not a
> protocol that should be promoted or supported by Resteasy or Picketlink,
> IMO.
I am unsure if "implicit" usecase implies insecure. All it does is
avoids the intermediate
authorization code grant step. It is useful for Javascript applications.
Very incorrect. There is nothing preventing Javascript applications
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.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com