On 09 Oct 2014, at 04:49, Bruno Oliveira <bruno(a)abstractj.org> 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