I was trying to perform a login with Google Service.

Hereby the executed code

let provider = Provider.Google(clientID: "$(the_client_id)", clientSecret: "$(the_client_secret)", redirectURL: "$(bundle_identifier):/urn:ietf:wg:oauth:2.0:oob")

provider.scopes = ["https://www.googleapis.com/auth/analytics.readonly"]

provider.authorize(self) { (result) in
    switch result {
    case .Success(let token):
        print(token)
    case .Failure(let error):
        print(error)
}

When the authorisation is granted in the Safari View Controller the redirect URL gets triggered with following format:

$(bundle_identifier):/urn:ietf:wg:oauth:2.0:oob?code=$(the_authorization_code)

This cause an issue for when the library checks if the redirect URL use during the initialisation of the Provider matches the received redirect URL from the AppDelegate.

I've tried other combination of redirect URL but that's the redirect URL format that the Google guide advocates.

Did anyone experienced this when trying the built in Google Provider?

I think an easy fix would be to match the retrieved URL by removing the GET parameter from the URL but before open a new PR I'd like to receive some feedback about this.

The OAuth Authentication process nowadays can be triggered from many devices equipped with different os: watch OS, iOS, tvOS.

Unfortunately, not all of this operating system can rely on a safe way to implement the OAuth 2.0 authentication flow:

• tvOS does not support SafariServices or Webkit.
• watchOS does not support SafariServices or Webkit.
• Today extension can not present webpages.

My idea to address this issue would be to implement for SwiftyOAuth following goals:

• [ ] Make the library use app extension API only.
• [ ] Add support for multiple platform: iOS, watchOS, tvOS.
• [ ] Improve -authorize method depending on current platform and capabilities.

What do you think?

From the docs:

Step 2: Handle the incoming requests

Handle the incoming requests in your AppDelegate:

func application(app: UIApplication, openURL url: NSURL, options: [String : AnyObject]) -> Bool {
    github.handleURL(url, options: options)

    return true
}

Unfortunately, while I was following the README, I found out that that the delegate method signature is slightly different:

func application(application: UIApplication, openURL url: NSURL, sourceApplication: String?, annotation: AnyObject) -> Bool

This causes an inconsistency with the designated method to handle an URL from the Provider.

    /**
     Handles the incoming URL.

     - parameter URL:     The incoming URL to handle.
     - parameter options: A dictionary of launch options.
     */
    public func handleURL(URL: NSURL, options: [String : AnyObject])

I think it should be rewritten in something like:

public func handleURL(URL: NSURL, sourceApplication: String?) 

Such that the Step 2 from the README would look like:

func application(application: UIApplication, openURL url: NSURL, sourceApplication: String?, annotation: AnyObject) -> Bool {
    github.handleURL(url, sourceApplication: sourceApplication)

    return true
}

In Token.swift, this init makes the all 3 parameters mandatory:

        guard let
            accessToken = json["access_token"] as? String,
            tokenType = json["token_type"] as? String,
            scope = json["scope"] as? String
        else { return nil }

However, Instagram only returns access_token

{
    "access_token": "2342264381.bc3c943.6086017a221b427a997e4928f0ea197b",
    "user": {
...
    }
}

What do you think about this:

    internal init?(json: JSON) {
        guard let
            accessToken = json["access_token"] as? String
        else { return nil }

        self.accessToken = accessToken

        self.tokenType = json["token_type"] as? String ?? ""
        self.scope = json["scope"] as? String ?? ""

        self.dictionary = json
    }

Summary

Authenticate NSURLRequest as specified by OAuth 2.0 guidelines for token type Bearer.

The Provider exposes a convenience method that, in case the available token is expired, refreshes the token and then uses it to authenticate any NSURLRequest.

Why

This feature give to the client an easy way to integrate a valid access token, retrieved via OAuth 2.0, in any NSURLRequest that the client might have created beforehand.

Note

To improve test cases accuracy I needed to add a dependency for the test target: OHTTPStubs.

I found the best way to do it via Carthage. To get started run the shell script in the bin folder.

Summary

Abstracted the logic for storing and retrieving a Token to a protocol, such that any object that conforms to it can be used to store and retrieve a Token type.

Why

By abstracting the implementation of the logic responsible to store/retrieve an object to a protocol, the user's of the library can provide his own [..]TokenStore that better fits his needs.

i.e.: this feature made possible to support iCloud Key Value Store very easily by gaining the opportunity to store a Token in the iCloud Key Value Store Container.

Note

As proof of concept I've implemented this protocol to support NSUserDefaults and NSUbiquitousKeyValueStore.

Summary

Implementation for #13

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

When storing the existing Token, it already has proper created_at value. When restoring back using init(dictionary:) that original value should not be over-written.

As requested, keychain support should not be based on third-party libraries, but uses a small wrapper found at https://gist.github.com/jackreichert/414623731241c95f0e20

Hint: func setToken() should return a Bool value, but has to be changed at protocol level (TokenStore).

Summary

Improved initialisation and features provided by the Error enum struct in order to provide a better error handling in the library

Why

Currently there are few places in the code marked with a TODO about a better error handling. I hope this will help.

Attempt to present <SFSafariViewController: 0x7fc7ba018400> on <MyOauth.ViewController: 0x7fc7b860b070> whose view is not in the window hierarchy!

I hate to re-invent hot water so I picked up the Server Trust handling from Alamofire.

Added Extension to URLSession to pick up current serverTrustPolicy from HTTPConfig struct, which is public and can be set from any other module.

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.