I'm trying to implement ShareKit in my app; in the SHKConfig.h file, in the section where the Twitter applications settings are required, there is a line where I'm supposed to set the Callback URL:
I have opened a Twitter application on Twitter and filled all the fields there, but I'm not clear regarding to what data should be inserted in the Callback URL field:
Can anyone explain?
The callback parameter you write in your application settings in Twitter is ignored, you can write anything, example: http://www.google.com (anything will do since it is ignored).
When you add a callback url in the #define, its value will be sent to twitter in the owner authorization step, and will override the value that you previously wrote in the Twitter website. Weird, I know. It's related to this security vulnerability.
The callback parameter is the URL Twitter is going to send the user after authentication. When running in websites instead applications, the URL callback is used to recover control of the OAuth flow.
On Applications, you can set it to a custom scheme like myapplication://twitter and then register the scheme myapplication in your app. This way, after authentication, the Twitter website running in UIWebView or Safari launches that URL, which iOS knows is assigned to your app, and that's how you recover control of the OAuth flow.
That's the theory, I don't know exactly how ShareKit works. It may be that it runs the authentication on a UIWebView and detects the activity of the user to recover control manually, which is another way to do it.
I'm using new version of ShareKit and in sources there is this comment about callback for twitter:
Callback URL' should match whatever you enter in
SHKTwitterCallbackUrl. The callback url doesn't have to be an actual
existing url. The user will never get to it because ShareKit
intercepts it before the user is redirected. It just needs to match.
I set in twitter settings callback url as http://somecallbackurl.com, set this same in sources and it works like a charm! :]. Hope this help.
You can use this
func application(_ application:UIApplication, open url: URL, options: [UIApplicationOpenURLOptionsKey: Any]) -> Bool {
print("called")
let directedByTWTR = Twitter.sharedInstance().application(application, open: url, options: options)
return directedByTWTR
}
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
My application built upon spring-social-twitter that enables users to sign in with Twitter has stopped working recently.
I've got an error message as below:
Callback URL not approved for this client application. Approved callback URLs can be adjusted in your application settings
Note: I'm using Spring Social Twitter version 1.1.2.RELEASE. And if you use Spring Social Twitter version 1.1.0.RELEASE, you might get a slightly different error message as below:
POST request for "https://api.twitter.com/oauth/request_token" resulted in 403 (Forbidden); invoking error handler
Twitter recently (in May 2018) enforced that sign-in-with-Twitter users must whitelist callback URLs for security reasons (see the announcement).
This means callback URLs have to be explicitly and identically set up for all supported third-party applications. You can setup the callback URLs in your Twitter's application setup page: https://apps.twitter.com
For example, if your callback URL is http://localhost:8080/myApp/signin/twitter, you must add it to the list of Callback URLs in your Twitter's application setup page exactly as it is: http://localhost:8080/myApp/signin/twitter
See also the documentation on Twitter callback URLs.
I struggled with this since Twitter made the changes to increase security. My android app would use a callback URL and the same URL in the Intent Filter. But since the change, the URL I was using had to be registered in the Twitter developer portal. I was using ouath://myapp, but Twitter does not accept that as a valid URL (website).
After a bit of digging, I found that for apps you can specify any scheme but only as a scheme. For example I used myapp:// as the callback URL.
In my app, my callback URL was myapp://whatever, and in the Intent filter, I used :
<data android:scheme="myapp" android:host="whatever">
Twitter accepted the callback URL and it correctly redirected back to my app after the user authenticated with their Twitter credentials.
I has originally used just a normal website, and that worked too, but after validation by Twitter, it asked if I wanted to redirect to My App, or to a Chrome browser. Using the above approach it will simply return to your app.
After I did all this, I realized that I could have just added Oauth:// as a call back URL and my app would have worked without change.
I fixed it by adding those callback URLs to Twitter's whitelist.
twitterkit-{Twitter API Key}:// for iOS.
twittersdk:// for Android.
I'm trying an application that is able to display all and create new events for the Outlook calendar. I am using the MSAL library to get the authentication code. The problem is that although the login screen appears when I touch the buttons enter or cancel I do not notice any reaction. This is my code:
class OutlookManagerController: BaseViewController {
let oClientKey = "a07745a5-3b90-4385-a2b2-8223dbf68688"
let authScopes = ["openid+https://outlook.office.com/contacts.read+offline_access"]
func getAcessToken(){
if let application = try? MSALPublicClientApplication.init(clientId: oClientKey) {
application.acquireToken(forScopes: authScopes) { (result, error) in
if result != nil {
let userToken = result!.accessToken!
print(userToken)
} else {
print(error!.localizedDescription)
}
}
}
else {
print("Unable to create application.")
}
}
}
It would appear that you are not listening for the return of the auth code from the SFSafariViewController which MSAL launches when you call AcquireToken(). MSAL uses the SFSafariViewControllerfor login in order to enable better security and provide Single Sign-On across applications. You just need to set up a redirect URI that has the ability to call back your application and use the correct Issuer for your tenant.
That is the problem you are running in to. Sign in is successful, but Azure can't find it's way back to your app!
First, some groundwork.
System Webviews
Most modern OAuth2 libraries now use the System Webview for signing a user in. A System Webview is a browser component that an application can launch that appears to be part of the application but is actually an isolated process which runs the operating system's web browser. For iOS this is the SFSafariViewController and on Android it is Chrome Custom Tabs.
The benefit of the System Webview for singing a user in are numerous, including:
Better security. An application can not access the credentials typed in to a System Webview as it's an isolated browser process.
Today many applications use a username and password form or an embedded webview to get credentials. This allows an application to listen in and grab these credentials. Many companies have begun disallowing applications that have this kind of sign in. System Webviews ensures your app doesn't have this problem.
Single Sign-On. Once a user has signed in with the System Webview, a cookie is placed in the browser and that account is available to any application, preventing the need for a user to sign in to every app separately.
As more consumers and businesses leverage phone SMS and other factors as additional steps, having to redo this step as well as use your password is getting very annoying for customers. System Webviews remove this problem.
Better control. A user can choose which account to provide the application, or add a brand new account in the System Webview if supported.
You've seen Google and Microsoft make the transition to this System Webview with our latest SDKs as well as update our identity services, and it's to give the customer these protections and features. App Auth from the OpenID project, which has code contributed by both Google and Microsoft engineers among others, also provides this support.
System Webview Needs To Return Back To Your App
One of the things that might have occurred to you reading the above is this:
If an application now calls a System Webview for sign-in, and has no control over it, how do I get the tokens I need back from the System Webview?
The answer is that you must leverage the mechanisms each operating system has to call back the application, and then use the redirectURI from the OAuth2 protocol to return the response back to that application using that mechanism. It's almost exactly like how this works in a web browser. You get redirected away from the website to an identity provider for sign in, and then the identity provider uses the redirectURI to return the user back to the website with tokens in the response somewhere.
For iOS this done through Custom URL Schemes. A URL scheme is in the format of CFBundleURLScheme:\\CFBundleURLSchemes and is defined as:
CFBundleURLName
A string containing the abstract name of the URL scheme. To ensure uniqueness, it is recommended that you specify a reverse-DNS style of identifier, for example, com.acme.myscheme.
The string you specify is also used as a key in your app’s InfoPlist.strings file. The value of the key is the human-readable scheme name.
CFBundleURLSchemes
An array of strings containing the URL scheme names—for example, http, mailto, tel, and sms.
To register a URL type for your app, include the CFBundleURLTypes key in your app’s Info.plist file. The CFBundleURLTypes key contains an array of dictionaries, each of which defines a URL scheme the app supports.
How To Get A System Webview To Return To Your App
So, combining these two things, it's fairly simple what you need to do:
Figure out what your URL scheme will be for your app (e.g. appauth://abc123.
Tell Azure AD what your new URL scheme is, adding it as another redirectURI for your application.
Configure your application to listen for this URL scheme and launch the app
Configure the application itself to grab the token once this URL scheme launches your app (App Auth, as well our own MSAL libraries, do this for you!)
1. Figure out what your URL scheme will be for your app
You can read up on how to make URL schemes from Apple's Inter-App Communication documentation, but we recommend you use the scheme of appauth://<client id> (e.g. appauth://ab032846-efee-481f-b6bc-493aae92c432)
2. Tell Azure AD what your new URL scheme is
You need to add this URL scheme as a RedirectURI to your app. This is easy to do. Just visit https://apps.dev.microsoft.com/ and select your application. Scroll down to Custom App URIs under Native Applications and add your new redirectURI!
3. Configure your application to listen for this URL scheme
Add the following to your info.plist file as per Apple's instructions in Inter-App Communication. It should look something like this, although different apps will have different and additional URL schemes registered:
<key>CFBundleURLTypes</key>
<array>
<dict>
<key>CFBundleTypeRole</key>
<string>Editor</string>
<key>CFBundleURLName</key>
<string>ab032846-efee-481f-b6bc-493aae92c432</string>
<key>CFBundleURLSchemes</key>
<array>
<string>app-auth</string>
</array>
</dict>
</array>
4. Configure the application itself to grab the token
Although listening for a response back from a web browser to an application is a well known pattern for all iOS apps, the actual implementation varies by the identity SDK you use. For MSAL put the following code in your AppDelegate.m file:
func application(_ application: UIApplication, open url: URL, sourceApplication: String?, annotation: Any) -> Bool {
print("Received callback!")
MSALPublicClientApplication.handleMSALResponse(url)
return true
}
The code is rather easy to understand once you know the background above. This is all about receiving a response from the identity service by grabbing the URL that is returned and then giving everything in that URL back to the app so it can grab the tokens it needs to continue it's work.
That's it!
Your app should now work with Azure Active Directory. This pattern of the System Webview is common both across many Identity Providers (Microsoft, Google, Facebook) and mobile platforms.
This is documented in our sample application here.
func application(_ application: UIApplication, open url: URL, sourceApplication: String?, annotation: Any) -> Bool {
MSALPublicClientApplication.handleMSALResponse(url)
return true
}
I'm currently trying to implement GitHub Authentication via Firebase in an iOS app.
I've read through the docs and figured out what I have to do. I'm having trouble though, in implementing the communication between my app and the WebView where I authorize the application to get user's data. I currently have this code:
let url = urlComponents.url! // https://github.com/login/oauth/authorize + scope
// Not quite sure if I should use open(_:options:completionHandler:) to handle this operation.
guard UIApplication.shared.canOpenURL(url) else {
return
}
UIApplication.shared.open(url, options: [:], completionHandler: nil)
What this code does is bring the user to the browser with the GitHub authorization screen, type the password and then a blank screen shows up. Inspecting the URL in this blank screen, I've found out that it contains the parameter it should have, but I'm not quite sure how to pass this parameter to my code so I can proceed with the authentication.
Firebase doc says I should implement a Custom URL scheme to handle the OAuth callback, but I'm not sure how to do it.
Solved, solution was to edit GitHub's Authorization callback URL to have my custom URL scheme and then proceed through the documentation flow.
I'm attempting to hook my application into Flickr but having issues during the Authentication process.
I've followed instructions in:
https://github.com/devedup/FlickrKit
I've created a CFBundleURLTypes for my application (let's call it myapp://) and tested that it works (i.e. I type myapp:// in a safari). I've successfully called the authentication URL in Flickr, it shows the login, asks the user to grant my app the necessary permissions then instead of redirecting back to my app via my URL...it does nothing, and the app is not authenticated.
I used FlickrKit demo app replacing its api key/secret/CFbundleUrltypes with mines and the issue is the same, so the problem is not in the code but rather in the way i registered my app in flickr. Said that...I just followed the instructions in Flickr "Edit Authentication Flow" so I guess the issue is with the callback url I put in flickr. I used myapp://auth? as described in many posts in the internet but does not authenticate or call back my app.
This is not the same issue reported here:
Flickr Authentication Flow and iPhone
but rather similar to the unanswered post:
flickr callback URL not working
The Info.plist for the custom URL handler and the AppDelegate code are a copy&paste from the flickrKit demo app [no need to reinvent the wheel] and anyway even after changing api key secret and url in flickrKit demo app with mines...the app is not called back, so it must be something wrong in my app registration.
Anybody experienced a similar behavior ? i ruled out objective-c code and callback url as the issue, so what is left is the flickr part but not sure where to look for help... so i wrote this post.
Thanks for any tip,
dom
Probably this is a problem of api signature calculation. All the parameters passed via method should be used to calculate an api signature.