[aerogear-dev] [Android] - Refactoring OAuth2 configuration

[Bruno Oliveira]

On 2015-03-10, Matthias Wessendorf wrote:
> On Mon, Mar 9, 2015 at 5:56 PM, Summers Pittman <supittma at redhat.com> wrote:
>
> >  On 03/09/2015 12:50 PM, Matthias Wessendorf wrote:
> >
> >
> >
> > On Mon, Mar 9, 2015 at 5:34 PM, Summers Pittman <supittma at redhat.com>
> > wrote:
> >
> >> On 03/09/2015 12:15 PM, Erik Jan de Wit wrote:
> >> >> Because Facebook and Google are well known for not making arbitrary
> >> changes to public apis and configurations.
> >> >>
> >> >> More importantly as an Open Source project hitching our code to the
> >> configuration of a third party proprietary system is terrifyingly bad
> >> karma.  Push is an exception ONLY because there isn't an equvalent open
> >> solution which has the same reach to devices.
> >> > It’s just some configuration, what point does oauth2 have when it
> >> doesn’t work with Facebook and Google.
> >> /me looks at the shoot and share demo, and the gdrive demo.
> >> Looks like it does work with FB and Google.  Did you have a specific
> >> example in mind?
> >> > The whole point of our libs is to make it easy for developers to do
> >> these complex things adding this config makes it super easy.  I don’t see:
> >> ”Terrifyingly bad karma” a good reason not to do this.
> >> Because it is hitching our open source project to the largess of
> >> proprietary service vendors.  If they change THEIR configuration and OUR
> >> libraries break WE look like the bad guys not them for starters.
> >>
> >
> >  That happened with push (Google's documentation, not the APIs) in the
> > past, and may happen again. We reacted pretty quick on that one, which is
> > what matters. If we would not react, we would look bad.
> >
> >  Perhaps we can add a statement that the code executes against a 3rd
> > party service, that we don't own. That can even happen with differen
> > Keycloak versions. However, usually actual API changes from the big players
> > are usually announced, and it's usually comes with a little bit of time to
> > react.
> >
> >
> >>
> >> Additionally the only direction this can go is toward scope creep. Once
> >> we have Facebook and Google nothing is stopping (rhetorically) from
> >> adding Facebook, Yahoo, VK, Microsoft, etc.  Now we are maintaining 5x
> >> as many configurations as we were before.
> >
> >
> >  I'd not add more, out of the blue. But if there is demand (from which
> > ever direction), it's time to react on that demand, but not before
> >
> >
> >> Who is going to monitor those
> >> APIs and make sure they don't break/get deprecated?  Do we cut a release
> >> because one auth provider changed their config?
> >>
> >> Of course we don't because that is the responsibility of the app
> >> developer to make sure their configuration for the services they consume
> >> is up to date.  It is not and should not be our responsibility.
> >>
> >> I freely admit it is nice and it is convenient but it does not belong in
> >> the project.
> >>
> >
> >  Instead, we don't offer any concrete impls for Google or Facebook?
> >
> > Correct
> >
> >   Or use a complicated and generic API, which may work, or not?
> >
> > The API works as long as the service correctly implements and documents
> > their OAuth2 parameters.
> >
> > I don't see how providing the OAuth2 parameters required by the
> > specification we implement makes this a complex API.  It is 2 fields
> > (client id and client secret) per client and 5 fields (the various
> > endpoints and base urls) per service.
> >
>
>
> Should we provide guides or tutorials, how to use the generic API against a
> very few (e.g. FB and Google) services ?

I'm already doing it, please see AGSEC-200

>
>
>
>
> >
> >
> >>
> >>
> >> >
> >> >
> >> > _______________________________________________
> >> > aerogear-dev mailing list
> >> > aerogear-dev at 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 at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>
> >
> >
> >
> >  --
> > Matthias Wessendorf
> >
> > blog: http://matthiaswessendorf.wordpress.com/
> > sessions: http://www.slideshare.net/mwessendorf
> > twitter: http://twitter.com/mwessendorf
> >
> >
> > _______________________________________________
> > aerogear-dev mailing listaerogear-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> >
> >
> > --
> > Summers Pittman
> > >>Phone:404 941 4698
> > >>Java is my crack.
> >
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf

> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


--

abstractj
PGP: 0x84DC9914