On Aug 26, 2013, at 1:29 PM, Kris Borchers <kris(a)redhat.com> wrote:
On Aug 26, 2013, at 12:25 PM, Lucas Holmquist <lholmqui(a)redhat.com> wrote:
> On Aug 26, 2013, at 1:16 PM, Kris Borchers <kris(a)redhat.com> wrote:
>> On Aug 26, 2013, at 12:11 PM, Lucas Holmquist <lholmqui(a)redhat.com> wrote:
>>> We are planning on adding an OAuth2 adapter to the JS library for 1.3.0. We
are going to code against the google OAuth2 playground stuff, but trying to follow the
spec as much as possible and try to be as generic as we can.
>>> I'm not sure if this should be an "adapter" or something
different. If it is an adapter of the Authentication plugin( not sure what we are
calling the different pieces. pipeline, data manager, etc.), then we should expect to see
authentication methods( enroll, login, logout ), but i think this "adapter"
should be much more than that.
>> If implementing those methods is possible, I would like to see this as an Auth
adapter but then with the other useful functionality on top. If not possible, then do you
have a proposal of what an OAuth2 plugin would look like?
> Just using Google As an example, i'm not sure if there would be an
"enroll" method, since that would be google's flow. but we could do
login/logout. I don't think enroll would really work anywhere since you would need
to do the token "dance" first. I see OAuth stuff more of an authorization api
than an authentication api
> let me gist a workflow for a standalone thing.
I would like to see that but what you are saying makes sense. It sounds like where I was
headed with the Basic and Digest adapters before I ran into browser security issues with
headers. I think and authorization API that basically just wraps itself around secured
endpoints works for me.
taken from googles doc's on OAuth2 client side flow:
>>> It should be used to connect to secured services( api ) that a user allows,
such as GCM for chrome or the google+ platform, or some other enterprisey thing.
>>> I'm wondering if this should be a standalone thing. I kind of like this
idea so when we do social login, which will most likely have OAuth2, we can just access
>>> aerogear-dev mailing list
>> aerogear-dev mailing list
> aerogear-dev mailing list
aerogear-dev mailing list