In the project I’m working on the original code was unable to extract the (otherwise correct) expiration date from the authentication server’s response (Azure AD). The modified code works just fine.

For case of 401, the network response may include some more info that we want to notify in the completion handler, rather than just the statusCode

So this allows consumer to specify the parse function to do that

@zenangst @RamonGilabert All right, so it was a long way of many commits, but the library is apparently working (tested it with one real project), public API is good I believe, and code has been refactored so many times that it couldn't be better. Should surely work with Azure SSO, and every other OAuth2 service, at least I truly believe in that :smile:

Usage:

• Setup:

let config = AuthConfig(
  clientId: "client-id",
  accessTokenUrl: NSURL(string: "access-token-url")!,
  accessGrantType: "authorization_code",
  authorizeURL: NSURL(string: "authorise-url")!,
  changeUserURL: NSURL(string: "change-user-url")!,
  redirectURI: "yourapp://auth")

config.extraAccessTokenParameters = ["resource": "resource"]
config.extraRefreshTokenParameters = ["resource": "resource"]

let service = AuthService(name: "service", config: config)
AuthContainer.addService(service)

• Safari app will be opened by default for authorisation, if it's iOS9 and you'd like to use SFSafariViewController, there is a ready-to-use class for you:

// SFSafariViewController will be presented on top of provided controller
service.config.webView = SafariWebView(viewController: viewController) 

• Show a login web page:

AuthContainer.serviceNamed("service")?.authorize()

• Handle response. If you use SafariWebView it will be dismissed _automagically_:

func application(app: UIApplication, openURL url: NSURL, options: [String : AnyObject]) -> Bool {
   AuthContainer.serviceNamed("service")?.accessToken(URL: url) { accessToken, error in
      if let accessToken = accessToken where error == nil {
         // User is logged in!!!
      }
   }
}

• Get an access token to include it in the each request. If token is about to expire it will be refreshed _automagically_, so you always get an active token is the completion closure:

AuthContainer.serviceNamed("service")?.accessToken(completion)

• If you need to change user and have a separate URL for that:

AuthContainer.serviceNamed("service")?.changeUser()

• If you don't have authorisation by code, but by username and password, there is a flow:

let config = AuthConfig(
  clientId: "client-id",
  accessTokenUrl: NSURL(string: "access-token-url")!,
  accessGrantType: "password")

let service = AuthService(name: "service", config: config)
AuthContainer.addService(service)

let parameters = ["username": "weirdo", "password": "123456"]
service.accessToken(parameters: parameters) { accessToken, error in
 // Ready!
}

• If you need to get your tokens, expiry date, username, user UPN:

let accessToken = AuthContainer.serviceNamed("service")?.locker.accessToken
let userUPN = AuthContainer.serviceNamed("service")?.locker.userUPN

And yeah, you could add as many auth services as you want if you have some crazy setup in the app. Just register a new one with a different name:

let service = AuthService(name: "another-service", config: config)

This PR includes a few small tweaks to make OhMyAuth compile successfully using the Swift 4.2 compiler. It also includes a bug fix I've made on our fork, which you might want to include in the main repo. Let me know if you want me to take any of these out 🙂

• Remove concurrency from token queue, since it relies on being serial in order to work.
• Use the latest recommended Xcode project settings.
• Replace open with public for properties and methods that can't be overridden anyway.
• Remove an iOS <8.2 code path that's no longer used and won't compile anymore.

Note that the project still uses Swift 4.0, I haven't changed that.

There is an edge case not handled by the current code. I’ve run into this issue on an earlier project (using a home-grown OAuth solution).

If the user successfully authorizes, but then doesn’t use the app for at least two weeks, the refresh token also expires (at least with Azure AD). In this case next time app is opened and an access token refresh is attempted, it will fail. In the other project I’ve handled this edge case with an attempt to authorize again (and perform any code block waiting for the access token, if succeeded). The aim was to provide as smooth UX as possible if it went wrong.

I’m not sure if the solution in this PR is the right one (I’m happy to share the Objective-C code from that earlier project with you), but we should get started somewhere.

• Update Cartfile as Keychain swift-3 branch has been merged to master
• We should release Keychain first, as this depends on Keychain. However, Keychain name has been registered on cocoapods, we need another podname. However, this PR just bump podspec version to mark this milestone

It seems like we had a brain-fart earlier when trying to fix this logic. If you analysis the statement it should be pretty straight forward to see that the expiryDate should be in the past and not the future. Otherwise it would cause it to always refresh the token, unless of course it was expired and then it would end up doing nothing.

I think it’d be useful to add a way to logout/deauthorize. The completion is to let the client to do its own post-logout clean-up. Unfortunately the browser controller can’t be closed automagically in this case because we don’t get notified about the event.

This patch fixes a bug that would cause all network related errors (such as when the user is offline) as opaque OhMyAuthError.internalError, which prevents the appropriate error handling to be done in clients.

The problem was that the logic dealing with responses was first checking if a valid HTTPURLResponse was received before checking the error. This patch simply flips the order of those two operations.

Tests have also been implemented for NetworkRequestable.

This change makes it so that a refresh token is no longer required in the data returned from a network request. Some authentication services do not reply with a refresh token, making all requests fail. The change is to only assign the current locker’s refresh token if it exists in the data.

• I think the window minimumValidity is used as a safe range to refresh the access token. This should be + instead of -
• This adds some more tests just to make sure