Fabulous news. Will provide feedback. On Jan 24, 2013, at 4:43 PM, Bill Burke <bburke(a)redhat.com&gt; wrote: > http://bill.burkecentral.com/2013/01/24/resteasy-3-0-beta-2-released-with... > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > security-dev mailing list > security-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/security-dev

I need to write up how it works too. I extended OAuth2 a tiny bit as well as JWT. If you check out the code, you'll also see I started on an IDP. If Picklink is ready, I could start implementing on top of it and/or contribute to the current effort you have on openshift. Let me know. The current release's experience is a bit limited because you're lacking extra metadata that our own IDP could provide. My current vision on oauth clients is: * THey must be registered * They are granted oauth and/or login permissions * If they are only granted oauth permissions, they must also have the set of roles that they are allowed to obtain from a user Code: https://github.com/resteasy/Resteasy/tree/master/jaxrs/security/skeleton-... On 1/24/2013 7:24 PM, Anil Saldhana wrote: > Fabulous news. Will provide feedback. > > On Jan 24, 2013, at 4:43 PM, Bill Burke <bburke(a)redhat.com&gt; wrote: > >> http://bill.burkecentral.com/2013/01/24/resteasy-3-0-beta-2-released-with... >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> _______________________________________________ >> security-dev mailing list >> security-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/security-dev

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. 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. On 2/19/2013 11:55 AM, Anil Saldhana wrote: > Bill, > I am unsure the RESTEasy Oauth support has all the grant types: > https://docs.jboss.org/author/display/PLINK/OAuth+Theory > > I am looking here: > https://github.com/resteasy/Resteasy/tree/master/jaxrs/security/resteasy-... > > Regards, > Anil > > > On 01/25/2013 08:21 AM, Bill Burke wrote: >> I need to write up how it works too. I extended OAuth2 a tiny bit as >> well as JWT. If you check out the code, you'll also see I started on an >> IDP. If Picklink is ready, I could start implementing on top of it >> and/or contribute to the current effort you have on openshift. Let me >> know. >> >> The current release's experience is a bit limited because you're lacking >> extra metadata that our own IDP could provide. >> >> My current vision on oauth clients is: >> >> * THey must be registered >> * They are granted oauth and/or login permissions >> * If they are only granted oauth permissions, they must also have the >> set of roles that they are allowed to obtain from a user >> >> Code: >> >> https://github.com/resteasy/Resteasy/tree/master/jaxrs/security/skeleton-... >> >> On 1/24/2013 7:24 PM, Anil Saldhana wrote: >>> Fabulous news. Will provide feedback. >>> >>> On Jan 24, 2013, at 4:43 PM, Bill Burke <bburke(a)redhat.com&gt; wrote: >>> >>>> http://bill.burkecentral.com/2013/01/24/resteasy-3-0-beta-2-released-with... >>>> -- >>>> Bill Burke >>>> JBoss, a division of Red Hat >>>> http://bill.burkecentral.com >>>> _______________________________________________ >>>> security-dev mailing list >>>> security-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/security-dev > > _______________________________________________ > security-dev mailing list > security-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/security-dev >

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

Hi Bruno, I think that is the usecase for implicit grant type in OAuth2. It is used when the client cannot save any secrets or tokens such as Javascript applications. Regards, Anil On 02/20/2013 05:42 AM, Bruno Oliveira wrote: > Hi Anil, > > Are you thinking in something like this? https://developers.google.com/accounts/docs/OAuth2#clientside > > If yes, makes sense. > > > -- > "The measure of a man is what he does with power" - Plato > - > @abstractj > - > Volenti Nihil Difficile > > > > On Tuesday, February 19, 2013 at 11:05 PM, Anil Saldhana wrote: > > > 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 > > > > _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org (mailto:security-dev@lists.jboss.org) https://lists.jboss.org/mailman/listinfo/security-dev

I will be working with Bill to streamline our OAuth implementation. I dont care if OAuth stays in RESTEasy or PicketLink as long as our users have support for OAuth from JBoss community. On 02/20/2013 09:55 AM, Bruno Oliveira wrote: > 'kk what's the plan for PicketLink use amber > (https://github.com/picketlink/picketlink/tree/master/oauth/src/main/java/...) > or Bill's implementation? > > Or both? > > -- > "The measure of a man is what he does with power" - Plato > - > @abstractj > - > Volenti Nihil Difficile > > On Wednesday, February 20, 2013 at 12:26 PM, Anil Saldhana wrote: > >> Hi Bruno, >> I think that is the usecase for implicit grant type in OAuth2. It >> is used when the client cannot save any secrets or tokens such as >> Javascript applications. >> >> Regards, >> Anil >> >> On 02/20/2013 05:42 AM, Bruno Oliveira wrote: >>> Hi Anil, >>> >>> Are you thinking in something like this? >>> https://developers.google.com/accounts/docs/OAuth2#clientside >>> >>> If yes, makes sense. >>> >>> >>> -- >>> "The measure of a man is what he does with power" - Plato >>> - >>> @abstractj >>> - >>> Volenti Nihil Difficile >>> >>> On Tuesday, February 19, 2013 at 11:05 PM, Anil Saldhana wrote: >>> >>>> 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 >>> >> _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev

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.

> > 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.