i think this could be interesting.

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?

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 :)

not sure i’ve looked at the java version  :)

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?


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

[2] - https://gist.github.com/abstractj/04136c6df85cea5f35d1

[3] - https://issues.jboss.org/browse/AGSEC-180

[4] - https://issues.jboss.org/browse/AGSEC-190

PGP: 0x84DC9914
aerogear-dev mailing list

aerogear-dev mailing list