I still don't quite get it.
As far as I understand it we should do https redirects instead of using custom url schemes because everyone could define the custom schemes into their apps. Why are then Apple's solutions SFAuthenticationSession(used before iOS 12), ASWebAuthenticationSession designed to use custom url schemes?
We have universal links enabled, so I thought it should be fairly easy to use a universal link. To test that I passed the https redirect to the ASWebAuthenticationSession and checked in the application:continueUserActivity:restorationHandler: callback in the app delegate for the redirect. It worked. Trying the same thing for the SFAuthenticationSession on iOS 11 on the other hand fails.
Am I overlooking something here? Isn't this really a security problem or am I listening at the wrong place to get the callback for the SFAuthenticationSession?
Related
In Twitter's Developer Documentation we can read the following:
Mobile apps with app-specific protocols must use just the protocol
Example:
You want to use example://authorize as your callback URL
Add this to both your Twitter app dashboard and your call to oauth/request_token: example://
However; in the Developer's Dashboard I am not able to enter a protocol only URL, or any URL beginning with other than http or https.
My reason for wanting a protocol only URL is so that I can use in an iOS app that uses OAuthSwift to access web APIs.
Any ideas anybody?
I haven't found the answer to the original question but I do have an excellent work around. So, for anyone else who might land here:
The web app at https://oauthswift.herokuapp.com/callback
will perform redirections. If you access that web site with the url https://oauthswift.herokuapp.com/callback/target then it will redirect to oauth-swift://oauth-callback/target.
So:
In the Twitter Dashboard enter https://oauthswift.herokuapp.com/callback/SomeName for your app's callback URL
Register oauth-swift as a URL scheme in your iOS app's URL Types
In your iOS app, use https://oauthswift.herokuapp.com/callback/SomeName as the callback URL for the OAuth authorization request.
Voila. Twitter will redirect to https://oauthswift.herokuapp.com/callback/SomeName which will in turn redirect to oauth-swift://oauth-callback/SomeName, allowing your iOS app to regain control of the flow.
If you find any of this confusing then this might help: http://iosdevelopertips.com/cocoa/launching-your-own-application-via-a-custom-url-scheme.html
In my application I am implementing a feature where for some part I need to open my website using SFSafariViewController. For this I don't want the user to login again in the web application as well, so before I open the SFSafariViewController I want to pass some token, mail and other required information. So is this feasible and would allow me to use browser cache.
SFSafariViewController is very limited in what you can configure, as seen by the documentation: https://developer.apple.com/documentation/safariservices/sfsafariviewcontroller. Apple intentionally keeps cookies and safari configuration separate from apps that are using it for security and privacy reasons.
I don't know if this is exactly what you're seeing, but I faced a similar issue where, if a user logged in via SFSafariViewControler, then logged out (not using SFSafariViewController), then logged in again, it wouldn't ask for a login/pass because it was still cached in the browser.
Pretty much the only 2 options for this are:
Have the logout flow take place within SFSafariViewController so that you can clear the cookies that way.
Apple has a new auth flow class ASWebAuthenticationSession (docs here) which has a new property you can set called prefersEphemeralWebBrowserSession which essentially opens the browser in private mode. This keeps any cookies from being stored in the browser. The only downside to this, is the prefersEphemeralWebBrowserSession property is only available in iOS 13+.
If this is the same issue you're facing and you can limit your app to iOS 13+, then I would suggest the ASWebAuthenticationSession route, otherwise you may need to find another solution.
Everything was working fine until today I've tried to test Safari Facebook login mechanism on my app and I started getting the following error on web browser:
The redirect_uri URL must be absolute.
I'm not using the Facebook SDK (for various reasons outside the question's context, so don't ask why) and I'm trying to open the following URL manually:
https://www.facebook.com/dialog/oauth?client_id=MY_APP_ID&response_type=token,granted_scopes&redirect_uri=fbMY_APP_ID://&scope=user_friends,user_birthday,email,user_photos&default_audience=friends&sdk=ios
Everything was working fine, until today where I realized that the URL isn't executing properly. I didn't change any app settings or anything. How can I complete my login flow? Yes, I need to redirect back to fbAPP_ID:// to launch my app back when using iOS versions lower than 9.0 where native Safari isn't supported. Or is there any known way of redirecting back to the application pre-iOS 9 from external Safari? (other than me redirecting to website, then on my website, redirecting back to my app by force opening fbAPP_ID:// from Javascript)
The only "redirect_uri" that works out of the box is fbAPP_ID://authorize , this is the one used by the Facebook SDK and anyone can use it as well.
Our iphone app allows for sign in via Foursquare via oauth. It was working fine and recently stopped working.
The error we get is: Connecting Failure: Callback uri is not valid for this consumer.
HOWEVER, if the user does not have the foursquare app installed on their phone it works fine as before. It seems as if FS is now doing a redirect to handle the oauth inside the FS app and this fails when attempting to return to the originating application. Via safari it seems to work.
This is on ios 9.
Solutions?? Thanks!
We've changed to use a SafariViewController and this seems to force Foursquare to not to this strange in-app redirect, solving the issue. This is also Apple's preferred oauth method, so probably the way to go.
Still seems like a problem on the Foursquare side that they may want to address for others however. I'm closing this question. Thanks.
Where does your redirect URL point? If you want it to launch your app after completion you should point to the iTunes store (pre-iOS9) link for your app or the universal link (iOS9 onwards).
More information on redirects for the native foursquare app is available in the README here: https://github.com/foursquare/foursquare-ios-oauth/
How to create a universal link in iOS9 https://www.appsflyer.com/blog/how-to-set-up-ios-9-universal-links-for-your-app/
A callback url is a webpage loaded after your web app has been
verified. In this case, you need to specify a page for to send data to
after authentication
Double check your Foursquare credentials and update the callback uri to a valid link. Tutorial link
Please follow the below points, may be one resolves your issue:-
Enter the callback in foursquare account in addcallback methods. Then in your code add the call back to the provider before you authorize. (Reference here).
You're getting that error because the URL you're pointing your users to (foursquare.com/oauth2/...) includes a redirect_uri parameter that doesn't match with what you configured in your app's settings under https://foursquare.com/developers/apps. Make sure these match!
The account settings page for registering an app accepts just valid http:// url schemes. We would require a custom url scheme in order to redirect back to our iOS app. Is there currently a way to provide a custom url scheme or if not, would it be possible to allow custom URL schemes from your side?
(I work at Asana.) We agree those would be useful. There is currently no way to use non-http schemes but we will look into adding them soon. Stay tuned!