trivago / Heimdallr.swift

Easy to use OAuth 2 library for iOS, written in Swift.
Apache License 2.0
639 stars 86 forks source link

How to pass scope when using resource owner flow? #88

Open omerlh opened 8 years ago

omerlh commented 8 years ago

Hey I've am using this library in our app to request a token based on resource owner flow. My question is - how I should pass the scope? I've finally managed to do it using this code:

 var oauthparams = OAuthAuthorizationGrant.ResourceOwnerPasswordCredentials(username, password).parameters
        oauthparams["scope"] = "red"

        heimdallr.requestAccessToken(grantType: "password", parameters: oauthparams) { result in
            switch result {
            case .Success:
                print("success")
            case .Failure(let error):
                print("failure: \(error)")
            }
        }

But this does not feel right. In the other hand, if this is the way to do this, maybe consider adding it to the readme, or add an overload (I can create a PR). As far as I know scope is required in this flow...

Thanks Omer

bckr commented 8 years ago

Hey!

regarding to RFC, passing a scope is optional. Unfortunately we don't support this right now in a more elegant way than you described already. We currently offer two public methods for requesting the access token:

public func requestAccessToken(username username: String, password: String, completion: Result<Void, NSError> -> ())
public func requestAccessToken(grantType grantType: String, parameters: [String: String], completion: Result<Void, NSError> -> ())

Only having had a short look at it, we could think about deprecating those in the long term and just using a single function that takes a OAuthAuthorizationGrant as its parameter like we do here. The only problem that I see here is that we would expose a manual way to refresh the access token. Maybe we can finde a way around this? What do you think?

In the other hand, if this is the way to do this, maybe consider adding it to the readme, or add an overload (I can create a PR).

A pull request would be awesome 👍

omerlh commented 8 years ago

Hey, Thank for you for your response! What do you think of an extension that received grant type and scope and call to this func? This will not expose anything that is not public already...

bckr commented 8 years ago

Hey! I think an extension is a nice temporary solution, but for the framework itself I would prefer deprecating the current request functions and introducing a unified one that takes an OAuthAuthorizationGrant. I currently can't find the time to do it myself. Would you like to tackle this in a pull request? Happy to give you pointers in the right direction 😊

omerlh commented 8 years ago

Maybe expose only one function that receive grant and params? Or only params as the grant can be part of the params? Than we can add extension methods for specific grants. What do you think?