On Nov 3, 2014 1:53 AM, "Corinne Krych" <corinnekrych@gmail.com> wrote:
>
>
> On 30 Oct 2014, at 19:13, Lucas Holmquist <lholmqui@redhat.com> wrote:
>
> >
> >> On Oct 30, 2014, at 9:41 AM, Matthias Wessendorf <matzew@apache.org> wrote:
> >>
> >> Hello team!
> >>
> >> On Thu, Oct 9, 2014 at 4:49 AM, Bruno Oliveira <bruno@abstractj.org> wrote:
> >> Note: Not only for Keycloak, but also compatible with other technologies
> >> like passport on Node.js.
> >>
> >> 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?
> >
> > So to clear up some confusion that might be happening with what passport is, it is not an OAuth2 server thing.
> >
> > 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.
>
> 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.
> 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.
> Right?

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.

A number of paaport.js extensions exist providing a simplified api for dealing with a particular oauth implementation, eg:

https://github.com/jaredhanson/passport-google-oauth

A module integrating passport with keycloak might indeed be interesting.  Certainly augmenting the demo to show they play nice together should be useful.

Brian

>
> 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.
>
> >
> > 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 );
>
> +1 on keycloak/passport.js integration
>
> >
> >
>
> As we said passport itself is not an oauth2 provider. You could couple it with KC or
> another interesting integration is OAuth2rize + passport which provides an Oauth2 server. see [1], [2]
>
> [1] http://scottksmith.com/blog/2014/07/02/beer-locker-building-a-restful-api-with-node-oauth2-server/
> [2] https://github.com/jaredhanson/oauth2orize
>
> I’d love to take a deeper look at this example… wdyt Luke?
>
> >
> >>
> >> 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 :)
> >>
> >> 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.
> >>
> >> That way we will also learn how much Passport.js is actually different, similar to what we learned on how Google/FB are different ;-)
> >>
> >> 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.
> >>
> >> Any thoughts?
> >>
> >> -Matthias
> >>
> >>
> >> [1] https://github.com/aerogear/aerogear-backend-cookbook/tree/master/Shoot
> >>
> >>
> >>
> >> In the end, OAuth2 is just a protocol and
> >> should support other servers.
> >>
> >> - Should we provide examples for OpenID connect? Or abstractions?
> >>
> >> To track this issue, we have the following Jira[3] and another for
> >> OpenID connect[4]. Fell free to link to your respective project.
> >>
> >>
> >> [1] -
> >> http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-10-08-14.00.html
> >>
> >> [2] - https://gist.github.com/abstractj/04136c6df85cea5f35d1
> >>
> >> [3] - https://issues.jboss.org/browse/AGSEC-180
> >>
> >> [4] - https://issues.jboss.org/browse/AGSEC-190
> >> --
> >>
> >> abstractj
> >> PGP: 0x84DC9914
> >> _______________________________________________
> >> aerogear-dev mailing list
> >> aerogear-dev@lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>
> >>
> >>
> >> --
> >> Matthias Wessendorf
> >>
> >> blog: http://matthiaswessendorf.wordpress.com/
> >> sessions: http://www.slideshare.net/mwessendorf
> >> twitter: http://twitter.com/mwessendorf
> >> _______________________________________________
> >> aerogear-dev mailing list
> >> aerogear-dev@lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev