[aerogear-dev] [Android] - Refactoring OAuth2 configuration
Summers Pittman
supittma at redhat.com
Mon Mar 9 14:13:10 EDT 2015
On 03/09/2015 01:43 PM, Corinne Krych wrote:
> As I already mentioned it, we can move those configurations into
> social repo. Let me create a JIRA on iOS to decouple oauth2 vs social
> repo (social being dependant on oauth2).
> Sth we discussed and agreed upon with abstractj (I can't find the
> thread though, it might have being during security meeting).
> A nice entry point to demo OAuth2 is to use external providers as we
> did for shoot demo app.
>
> Another point i don't understand what so bad into renaming
> android-authz to android-oauth2?
Because this is an Authorization library not an OAuth2 library. When we
have intent based APIs available we will be able to receive callbacks
from other installed apps on the device which won't be OAuth2.
Also because renaming the library is a huge PITA and will break semver.
We had this discussion ad nauseam during 2.0 development.
>
> ++
> Corinne
>
> On 9 March 2015 at 17:58, Summers Pittman <supittma at redhat.com
> <mailto: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 <mailto: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.
> If we don't hard code their configuration into the API then when
> they change it we don't look bad. WIN-WIN
>>
>> 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.
> Back to who is responsible for monitoring the changes from these guys?
>>
>>
>> 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
> Fair enough. We have demand from VK already so why not add that
> on in right now?
>
>> 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? Or use a complicated and generic API, which may work,
>> or not?
>>
>>
>>
>> >
>> >
>> > _______________________________________________
>> > aerogear-dev mailing list
>> > aerogear-dev at lists.jboss.org
>> <mailto:aerogear-dev at lists.jboss.org>
>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>> --
>> Summers Pittman
>> >>Phone:404 941 4698 <tel:404%20941%204698>
>> >>Java is my crack.
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> <mailto: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 <mailto:aerogear-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> --
> Summers Pittman
> >>Phone:404 941 4698 <tel:404%20941%204698>
> >>Java is my crack.
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
>
> _______________________________________________
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150309/68aa22da/attachment-0001.html
More information about the aerogear-dev
mailing list