<p dir="ltr"><br>
On Nov 3, 2014 1:53 AM, "Corinne Krych" <<a href="mailto:corinnekrych@gmail.com">corinnekrych@gmail.com</a>> wrote:<br>
><br>
><br>
> On 30 Oct 2014, at 19:13, Lucas Holmquist <<a href="mailto:lholmqui@redhat.com">lholmqui@redhat.com</a>> wrote:<br>
><br>
> ><br>
> >> On Oct 30, 2014, at 9:41 AM, Matthias Wessendorf <<a href="mailto:matzew@apache.org">matzew@apache.org</a>> wrote:<br>
> >><br>
> >> Hello team!<br>
> >><br>
> >> On Thu, Oct 9, 2014 at 4:49 AM, Bruno Oliveira <<a href="mailto:bruno@abstractj.org">bruno@abstractj.org</a>> wrote:<br>
> >> Note: Not only for Keycloak, but also compatible with other technologies<br>
> >> like passport on Node.js.<br>
> >><br>
> >> Great point on being compatible with passport.js! To ensure our OAuth2 client SDKs do work against node.js (w/ passport.js), how about we build a Node.js based version of our "Shoot-n-Share backend" ([1]), that is protected by Passport.js?<br>
> ><br>
> > So to clear up some confusion that might be happening with what passport is, it is not an OAuth2 server thing.<br>
> ><br>
> > it’s really just middleware(think of it as a servlet filter for you java weenies) for express.js, and by using adapters(like a FB or google), it can secure RESTful endpoints in that express.js app.<br>
><br>
> So basically you can use passport to secure your endpoint using openId connect (on top of oauth2). you login as google user and your secure your endpoint with google access token.<br>
> with passport.js you can go the authz code grant way because you store token on server side. Refresh and access token are never stored in browser app.<br>
> Right?</p>
<p dir="ltr">The browser will include the returned oauth2 token with ever request to establish authorization. This token /may/ be stored as a cookie or in local storage to facilitate that until the user logs out.</p>
<p dir="ltr">A number of paaport.js extensions exist providing a simplified api for dealing with a particular oauth implementation, eg:</p>
<p dir="ltr"><a href="https://github.com/jaredhanson/passport-google-oauth">https://github.com/jaredhanson/passport-google-oauth</a></p>
<p dir="ltr">A module integrating passport with keycloak might indeed be interesting. Certainly augmenting the demo to show they play nice together should be useful.</p>
<p dir="ltr">Brian</p>
<p dir="ltr">><br>
> On native app we’re doing what passport.js is doing but directly on device… not sure there is anything interesting to demo on native app, it’s more a web or cordova thing. I would say either use key cloak/passport Js for web pure app and corodva app or use corodva native oauth2 plugin.<br>
><br>
> ><br>
> > I think the thing that we can do here is make a keycloack adapter for passport, using the OAuth2 protocol( similar to passports FB and google adapters );<br>
><br>
> +1 on keycloak/passport.js integration<br>
><br>
> ><br>
> ><br>
><br>
> As we said passport itself is not an oauth2 provider. You could couple it with KC or<br>
> another interesting integration is OAuth2rize + passport which provides an Oauth2 server. see [1], [2]<br>
><br>
> [1] <a href="http://scottksmith.com/blog/2014/07/02/beer-locker-building-a-restful-api-with-node-oauth2-server/">http://scottksmith.com/blog/2014/07/02/beer-locker-building-a-restful-api-with-node-oauth2-server/</a><br>
> [2] <a href="https://github.com/jaredhanson/oauth2orize">https://github.com/jaredhanson/oauth2orize</a><br>
><br>
> I’d love to take a deeper look at this example… wdyt Luke?<br>
><br>
> ><br>
> >><br>
> >> It could be a (simple) a 'clone' of our java version. I think for Luke, our Node.js pro, it would be a fairly simple task :)<br>
> >><br>
> >> On the client side, the Android/iOS versions of Shoot-n-Share would simply offer a new upload target for Passport.js, instead of 'just' FB, Google-Drive and Keycloak.<br>
> >><br>
> >> That way we will also learn how much Passport.js is actually different, similar to what we learned on how Google/FB are different ;-)<br>
> >><br>
> >> Another interesting aspect of this is that, once we are ready to release our OAuth2 SDKs, it would be awesome to actually ship a node.js based demo as well, instead of just a Java-based backend demo. That would clearly show, our client libs are working across different backend technologies.<br>
> >><br>
> >> Any thoughts?<br>
> >><br>
> >> -Matthias<br>
> >><br>
> >><br>
> >> [1] <a href="https://github.com/aerogear/aerogear-backend-cookbook/tree/master/Shoot">https://github.com/aerogear/aerogear-backend-cookbook/tree/master/Shoot</a><br>
> >><br>
> >><br>
> >><br>
> >> In the end, OAuth2 is just a protocol and<br>
> >> should support other servers.<br>
> >><br>
> >> - Should we provide examples for OpenID connect? Or abstractions?<br>
> >><br>
> >> To track this issue, we have the following Jira[3] and another for<br>
> >> OpenID connect[4]. Fell free to link to your respective project.<br>
> >><br>
> >><br>
> >> [1] -<br>
> >> <a href="http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-10-08-14.00.html">http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-10-08-14.00.html</a><br>
> >><br>
> >> [2] - <a href="https://gist.github.com/abstractj/04136c6df85cea5f35d1">https://gist.github.com/abstractj/04136c6df85cea5f35d1</a><br>
> >><br>
> >> [3] - <a href="https://issues.jboss.org/browse/AGSEC-180">https://issues.jboss.org/browse/AGSEC-180</a><br>
> >><br>
> >> [4] - <a href="https://issues.jboss.org/browse/AGSEC-190">https://issues.jboss.org/browse/AGSEC-190</a><br>
> >> --<br>
> >><br>
> >> abstractj<br>
> >> PGP: 0x84DC9914<br>
> >> _______________________________________________<br>
> >> aerogear-dev mailing list<br>
> >> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
> >> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
> >><br>
> >><br>
> >><br>
> >> --<br>
> >> Matthias Wessendorf<br>
> >><br>
> >> blog: <a href="http://matthiaswessendorf.wordpress.com/">http://matthiaswessendorf.wordpress.com/</a><br>
> >> sessions: <a href="http://www.slideshare.net/mwessendorf">http://www.slideshare.net/mwessendorf</a><br>
> >> twitter: <a href="http://twitter.com/mwessendorf">http://twitter.com/mwessendorf</a><br>
> >> _______________________________________________<br>
> >> aerogear-dev mailing list<br>
> >> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
> >> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
> ><br>
> > _______________________________________________<br>
> > aerogear-dev mailing list<br>
> > <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
> > <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
><br>
><br>
> _______________________________________________<br>
> aerogear-dev mailing list<br>
> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
</p>