[aerogear-dev] AeroGear iOS OAuth2 Swift 3 and pending PRs

[Corinne Krych]

Thank you Micheal!
Indeed a CocoaPods release is coming soon (coming week).

Response inline.

On 23 November 2016 at 18:29, Michael Doo <michael at 410labs.com> wrote:

> Hello,
>
> There's a big change to the AeroGear iOS OAuth2 library: it's now been
> migrated to Swift 3! 🎉🎉🎉 It still needs to be published to the main
> CocoaPods Specs repo for wider adoption (all 65 GitHub stars' worth), so if
> you want to use it, for now point your Podfile to the AeroGear repo. There
> are also three pending pull requests that I'd appreciate a review on:
>
> * #64 Update Podspec - A simple PR to update the version of the AeroGear
> iOS Http library that is required by the library
>
+1

> * #63 Add audience and server code - This allows developers to validate
> the refresh/access token request being made as well as do cross-client auth
> so a mobile app and server backend are essentially viewed as one
> application to be authorized
>

I need a closer look at this one. It would be nice to have a use case. Our
demo app is:
https://github.com/aerogear/aerogear-ios-cookbook/tree/master/Shoot
I wrote this article:
http://corinnekrych.blogspot.fr/2015/01/sharing-keychain-access-in-share.html
to talk about extension (ie cross-client via keychain sharing tokens) could
it be a use case?

* #62 Add ID token to auth response - Many OAuth2 providers now send a JWT
> ID token along with the other usual tokens that provides extra information
> about a user, e.g., user ID, address, phone number, etc.
>
agreed (PR merged)

>
> These PRs are pretty small, but I think add some good functionality to the
> library! My next planned pieces of work are:
>
> * Switch Google to use SFSafariViewController - Per a post on the Google
> dev blog (https://developers.googleblog.com/2016/08/modernizing-oauth-
> interactions-in-native-apps.html), they will soon be disallowing embedded
> web views to do the OAuth2 dance. The solution is to use
> SFSafariViewController (or just the regular Safari browser). This already
> exists in the library, but Google needs to be special-cased to never accept
> an embedded web view as an option.
>

Agreed it is in the todo list for a bit, here the jira
https://issues.jboss.org/browse/AGIOS-531


> * Better cookie management to support multiple accounts - Some services
> (like Google) provide an account picker for a user to choose from. This is
> a much better UX. However, not all OAuth2 providers are as cool as Google.
> For these providers, you cannot currently sign into multiple accounts using
> the OAuth2 library unless you clear cookies before the embedded web view is
> presented. Will be working on a solution to do this.
>
>
>  https://issues.jboss.org/browse/AGIOS-532 created for this one

> Best,
> Michael Doo
> 410 Labs
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20161124/c5ea973b/attachment-0001.html