SwiftyOAuth icon indicating copy to clipboard operation
SwiftyOAuth copied to clipboard

Support OAuth 2.0 Device Flow

Open fabiomassimo opened this issue 8 years ago • 12 comments

Device flow's goal is to implement OAuth 2.0 authorisation flow on devices with limited capabilities (i.e. no WebKit).

In my overview to support this:

  • [ ] Add new grant type: http://oauth.net/grant_type/device/1.0
  • [ ] Handle new error cases: "authorisation_pending" , "slow_down", "code_expired"
  • [ ] Extend the Provider with support to request an access token with new grant type.

fabiomassimo avatar Jun 13 '16 06:06 fabiomassimo

Do you have a use case in mind?

delba avatar Jun 13 '16 07:06 delba

OAuth 2.0 through an Apple TV.

  1. The user starts the handshake for requesting a device code depending on the provider requirements. This process involves a POST request to a proper URL. The specification about this are given by the provider. Here an example for Google.

  2. The user presents the proper UI in the app and asks to SwiftyOAuth to pull an access token through something like

public func authorizeDeviceCode(deviceCode: String, completion: Result<Token, Error>)
  1. A proper Access Token is returned and saved like usual.

fabiomassimo avatar Jun 13 '16 07:06 fabiomassimo

I edited the function signature. I thing the retry mechanism should be up to the user not to SwiftyOAuth.

fabiomassimo avatar Jun 13 '16 07:06 fabiomassimo

@fabiomassimo Check out the upcoming single sign-on feature for Apple TV :)

I guess we can close the issue?

delba avatar Jun 14 '16 19:06 delba

Unfortunately not, because it is only supported by apps that provide broadcasting content (HBO, CNN)

Please if you think this issue is not in scope feel free to close this. Otherwise I'd be happy to provide a PR for it. As far as I know this could be a first in the OAuth library out there.

fabiomassimo avatar Jun 14 '16 19:06 fabiomassimo

It's not out of the scope but it has to fit well in the lib. I don't want the implementation to be in the way of the more mainstream flows.

Also, while the multi-platform support is on the roadmap, there are other things I'd like to do first (Keychain etc.). Once these things out of the way, yes I'm all for it :)

delba avatar Jun 14 '16 19:06 delba

@fabiomassimo What's the status on it ? 😃

delba avatar Jun 27 '16 14:06 delba

Hi Damien, Sorry I didn't give you any update on this.

While doing my research I found this following nice implementations about Apple Keychain:

  • Heimdlarr: Easy drop in class solution.
  • Apple: Little bit too academic but gives nice hands on the Security Framework.

I wanted to make my own implementation as exercise but unexpected events made me really busy on something else. If you want to move forward I think I've to leave this to you.

fabiomassimo avatar Jun 27 '16 14:06 fabiomassimo

The keychain concern has already been taken care of ahaha https://github.com/delba/SwiftyOAuth/tree/keychain

I'm gonna merge it in master soon

delba avatar Jun 27 '16 14:06 delba

That's awesome!

Device Flow was already implemented in my personal fork.

I can merge from current keychain branch if you want to and open a PR with just Device Flow implementation.

fabiomassimo avatar Jun 27 '16 14:06 fabiomassimo

Yes, could you please rebase your work with the keychain branch and submit a PR?

I might merge everything in master by tomorrow

delba avatar Jun 27 '16 16:06 delba

Hi @fabiomassimo !

Just FYI I created a swift-3.0 branch 🚀 😄

delba avatar Aug 27 '16 14:08 delba