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

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Michael Doo
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
* #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
* #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.

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.
* 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.


Best,
Michael Doo
410 Labs

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [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 <[hidden email]> 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
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Loading...