On 09 Oct 2014, at 04:49, Bruno Oliveira <bruno(a)abstractj.org&gt; wrote: > Good morning, > > Today we had a meeting to discuss some of the priorities for security on > AeroGear[1]. One of the items is OAuth2 support. Currently we have > several great examples and implementations for GDrive, flows for > Keycloak and etc. > > Although is a bit confuse for developers getting started from scratch. > I would like to keep our libaries aligned, considering the limitations > of each technology of course, as well consolidate each flow[2]. > > Also the team agreed that OpenID connect (with Facebook and Google) should be considered a low > priority at the moment. That said I have some open questions: > > - Should we provide separated SDKs for OAuth2? Or let's put everything > into *-auth and break into modules later? Eventually we plan to split aerogear-ios-oauth2 and remove the providers specific bits either moving it to a aerogear-ios-social with subspec for each providers. We’ve implemented with that in mind (it’s decoupled). But with the reallity of working with Swift right now (lack of cocoa pods support, dynamic fwk issues etc…), we worked with painful github submodules and as Daniel said it all in his readme: "Now, it is even worst that our submodule also contains a submodule (sorry):” in https://github.com/danbev/aerogear-ios-sync-client#prerequisites and given each provider implementation is just 1 or classes, I prefer to do the split later. But yeah, planned and designed for it.

> > Note: Not only for Keycloak, but also compatible with other technologies > like passport on Node.js. In the end, OAuth2 is just a protocol and > should support other servers. Not a protocol, a framework, one might argue.

That’s why having different providers helps to make sure we are flexible enough. See https://tools.ietf.org/html/rfc6749#section-1.8 or http://en.wikipedia.org/wiki/OAuth#Non-interoperability => this is my motivation behind implementing google, fb oauth2 providers. Twitter should be next.

> > - Should we provide examples for OpenID connect? Or abstractions? As always I like demos to illustrate use cases. Within the shoot suite demos, we have: - a Shootn’Share mobile app to upload picture to Fb, Google and Keycloak, - a SharedShoo web app to see all users shared pictures uploaded to Keycloak. This app required a login. - we can add a SharedShoot mobile app with an open id login (3 options: login as Keycloak and eventually as fb, google) to see all users pictures.

Although OpenID Connect flow is really based on Oauth authz code, some extra steps are needed. For ex, decode toke to extract user information. Provide an abstraction around how to get user infer would be nice. I have a ticket for 2.1 (October/November release). https://issues.jboss.org/browse/AGIOS-282 https://issues.jboss.org/browse/AGIOS-287 On client side what we can also provide is a customized button for login as Facebook etc… For Keycloak it has to be a customizable one. and… one more thing (apple way) Do you have any ticket for SSO on native app? I have opened: https://issues.jboss.org/browse/AGIOS-285

> > 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/aerog... > > [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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Hi Bruno I’ve updated your gist with some comments. For the cookbook the place to look is: - for iOS client: https://github.com/aerogear/aerogear-ios-cookbook/blob/swift/Shoot/README.md - for backend: https://github.com/corinnekrych/aerogear-backend-cookbook/blob/master/Sho... Indeed we should rename iOScookbook in aerogear.org as it’s not releated to cookbook repo. this page should be removed as it has been replaced by this one: http://aerogear.org/docs/guides/aerogear-ios/ Let me open a JIRA for cleaning that. ++ Corinne On 09 Oct 2014, at 11:08, Corinne Krych <corinnekrych(a)gmail.com&gt; wrote: > > On 09 Oct 2014, at 04:49, Bruno Oliveira <bruno(a)abstractj.org&gt; wrote: > >> Good morning, >> >> Today we had a meeting to discuss some of the priorities for security on >> AeroGear[1]. One of the items is OAuth2 support. Currently we have >> several great examples and implementations for GDrive, flows for >> Keycloak and etc. >> >> Although is a bit confuse for developers getting started from scratch. >> I would like to keep our libaries aligned, considering the limitations >> of each technology of course, as well consolidate each flow[2]. >> >> Also the team agreed that OpenID connect (with Facebook and Google) should be considered a low >> priority at the moment. That said I have some open questions: >> >> - Should we provide separated SDKs for OAuth2? Or let's put everything >> into *-auth and break into modules later? > > Eventually we plan to split aerogear-ios-oauth2 and remove the providers specific bits either moving it to a aerogear-ios-social with subspec for each providers. > We’ve implemented with that in mind (it’s decoupled). > > But with the reallity of working with Swift right now (lack of cocoa pods support, dynamic fwk issues etc…), we worked with painful github submodules and as Daniel said it all in his readme: "Now, it is even worst that our submodule also contains a submodule (sorry):” in https://github.com/danbev/aerogear-ios-sync-client#prerequisites > and given each provider implementation is just 1 or classes, I prefer to do the split later. But yeah, planned and designed for it. > >> >> Note: Not only for Keycloak, but also compatible with other technologies >> like passport on Node.js. In the end, OAuth2 is just a protocol and >> should support other servers. > > Not a protocol, a framework, one might argue. > That’s why having different providers helps to make sure we are flexible enough. > See https://tools.ietf.org/html/rfc6749#section-1.8 > or http://en.wikipedia.org/wiki/OAuth#Non-interoperability > => this is my motivation behind implementing google, fb oauth2 providers. Twitter should be next. > >> >> - Should we provide examples for OpenID connect? Or abstractions? > > As always I like demos to illustrate use cases. > Within the shoot suite demos, we have: > - a Shootn’Share mobile app to upload picture to Fb, Google and Keycloak, > - a SharedShoo web app to see all users shared pictures uploaded to Keycloak. This app required a login. > - we can add a SharedShoot mobile app with an open id login (3 options: login as Keycloak and eventually as fb, google) to see all users pictures. > > Although OpenID Connect flow is really based on Oauth authz code, some extra steps are needed. For ex, decode toke to extract user information. Provide an abstraction around how to get user infer would be nice. I have a ticket for 2.1 (October/November release). > > https://issues.jboss.org/browse/AGIOS-282 > https://issues.jboss.org/browse/AGIOS-287 > > On client side what we can also provide is a customized button for login as Facebook etc… For Keycloak it has to be a customizable one. > > and… one more thing (apple way) > Do you have any ticket for SSO on native app? I have opened: > https://issues.jboss.org/browse/AGIOS-285 > >> >> 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/aerog... >> >> [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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On 10/08/2014 10:49 PM, Bruno Oliveira wrote: > Good morning, > > Today we had a meeting to discuss some of the priorities for security on > AeroGear[1]. One of the items is OAuth2 support. Currently we have > several great examples and implementations for GDrive, flows for > Keycloak and etc. > > Although is a bit confuse for developers getting started from scratch. > I would like to keep our libaries aligned, considering the limitations > of each technology of course, as well consolidate each flow[2]. > > Also the team agreed that OpenID connect (with Facebook and Google) should be considered a low > priority at the moment. That said I have some open questions: > > - Should we provide separated SDKs for OAuth2? Or let's put everything > into *-auth and break into modules later? *-auth should, IMHO, contain everything necessary to create an OAuth2 connection to anything that isn't broken. However, *-auth-facebook, *-auth-google, *-auth-herpDerpDeHur, etc may be useful to be full of convenience classes.

ON Android it may even be useful to have a *-auth-accountmanager to make working with Androids native token service easier.

> > Note: Not only for Keycloak, but also compatible with other technologies > like passport on Node.js. 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/aerog... > > [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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- Summers Pittman >>Phone:404 941 4698 >>Java is my crack. _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev