<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Aug 26, 2013, at 1:29 PM, Kris Borchers <<a href="mailto:kris@redhat.com">kris@redhat.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><br>On Aug 26, 2013, at 12:25 PM, Lucas Holmquist <<a href="mailto:lholmqui@redhat.com">lholmqui@redhat.com</a>> wrote:<br><br><blockquote type="cite"><br>On Aug 26, 2013, at 1:16 PM, Kris Borchers <<a href="mailto:kris@redhat.com">kris@redhat.com</a>> wrote:<br><br><blockquote type="cite"><br>On Aug 26, 2013, at 12:11 PM, Lucas Holmquist <<a href="mailto:lholmqui@redhat.com">lholmqui@redhat.com</a>> wrote:<br><br><blockquote type="cite">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. <br><br>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.<br></blockquote><br>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?<br></blockquote><br>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<br><br><br>let me gist a workflow for a standalone thing.<br></blockquote><br>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.<br></blockquote><div><br></div><div>taken from googles doc's on OAuth2 client side flow: <a href="https://developers.google.com/accounts/images/tokenflow.png">https://developers.google.com/accounts/images/tokenflow.png</a></div><div><br></div><br><blockquote type="cite"><blockquote type="cite"><br><br><blockquote type="cite"><blockquote type="cite"><br>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.<br><br>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 it. <br><br>Thoughts?<br><br><br><br><br>_______________________________________________<br>aerogear-dev mailing list<br><a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>https://lists.jboss.org/mailman/listinfo/aerogear-dev<br></blockquote><br><br>_______________________________________________<br>aerogear-dev mailing list<br><a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>https://lists.jboss.org/mailman/listinfo/aerogear-dev<br></blockquote><br><br>_______________________________________________<br>aerogear-dev mailing list<br><a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>https://lists.jboss.org/mailman/listinfo/aerogear-dev<br></blockquote><br><br>_______________________________________________<br>aerogear-dev mailing list<br><a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>https://lists.jboss.org/mailman/listinfo/aerogear-dev<br></blockquote></div><br></body></html>