<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 9, 2014 at 4:49 AM, Bruno Oliveira <span dir="ltr">&lt;<a href="mailto:bruno@abstractj.org" target="_blank">bruno@abstractj.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Good morning,<br>
<br>
Today we had a meeting to discuss some of the priorities for security on<br>
AeroGear[1]. One of the items is OAuth2 support. Currently we have<br>
several great examples and implementations for GDrive, flows for<br>
Keycloak and etc.<br>
<br>
Although is a bit confuse for developers getting started from scratch.<br>
I would like to keep our libaries aligned, considering the limitations<br>
of each technology of course, as well consolidate each flow[2].<br></blockquote><div><br></div><div>that is a nice matrix to reflect where our client libraries are!</div><div><br></div><div>Thanks! helpful!</div><div><br></div><div>-Matthias</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Also the team agreed that OpenID connect (with Facebook and Google) should be considered a low<br>
priority at the moment. That said I have some open questions:<br>
<br>
- Should we provide separated SDKs for OAuth2? Or let&#39;s put everything<br>
into *-auth and break into modules later?<br>
<br>
Note: Not only for Keycloak, but also compatible with other technologies<br>
like passport on Node.js. 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" target="_blank">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" target="_blank">https://gist.github.com/abstractj/04136c6df85cea5f35d1</a><br>
<br>
[3] - <a href="https://issues.jboss.org/browse/AGSEC-180" target="_blank">https://issues.jboss.org/browse/AGSEC-180</a><br>
<br>
[4] - <a href="https://issues.jboss.org/browse/AGSEC-190" target="_blank">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" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Matthias Wessendorf <br><br>blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a>
</div></div>