I have a single page app that integrates with other services such as Dropbox and LinkedIn. Dropbox, for instance, has great API and I got the authentication working by opening Dropbox's authentication link in another window. Once the user authenticates, I ask them to close that new window to return to my app.
Clearly this is suboptimal as it takes the user away from my app, and even more cumbersome on tablets.
How would I do the authentication within the app, such is in a lightbox or a modal form?
Note that the integration itself happens server-side not client side. Presently, the Dropbox authentication page has a call back page that signals to my server that authentication was successful, which I store in the user's table in the database for future use.
Note: The bounty comment should read: A code sample is highly desired but not required.
In general, the Dropbox API uses HTTP POST requests with JSON arguments and JSON responses. Request authentication is via OAuth 2.0 using the Authorization request header or authorization URL parameter.
If you'd like to quickly test out the Dropbox APIs using your own Dropbox account before implementing OAuth, you can generate an access token from your newly created app in My apps by pressing the button that says "Generate" in the OAuth 2 section of your app settings page.
Sign in to dropbox.com with your admin credentials. Click Admin console. Click Settings. Click App permissions under Apps.
What you're proposing is to defeat the security model, so it should not be possible. The user should be able to see the URL of the real page for verification. Imagine when you're making a payment with Paypal, you likely check that you're on paypal.com before entering your important data right? The same applies to all other apps. It's a very ugly flow, but the best the industry has come up with today.
The ideal flow is you redirect user to the third-party web site or app, user logs in and authorizes, then redirects back to you. A native app has the benefit of switching to another native app, so the flow is a bit less ugly.
The work around that would do what you want is an app asking for user's name and password to the 3rd party service, then doing the auth dance themselves behind the scenes. This will likely deter users from your app and is very dangerous. I do not recommend it.
You may load the authorization endpoint in a iframe on your webpage. However, notice that some browsers have limitations on cookies sent to the login provider within an iFrame. Typically (Safari, iOS) you have only read access to the cookies, which is sufficient if the session cookie is already set at the provider.
On your callback page - where you are sent back from dropbox after authentication; you will need to call a javascript function to trigger an event at the parent page, that authentication is done.
window.parent.AppController.authenticationComplete();
The parent then may remove the iframe, and proceed as authenticated.
authenticationCompleted = function() {
// [snipp]
$("iframe#loginwrapper").remove();
}
Because of the potential cookie problem, I'd reccomend you to perform all the authentication steps initiated from the server end, before the main HTML page is served at all. Then you will make sure that your app is not loaded twice. This is typical behaviour of many authentication/identity middleware software solutions.
When you mention app it is unclear whether you mean a pure WebApp, or if you have the control available in a hybrid app by using frameworks such as Phonegap. With Phonegap or similar, you may load a browser inside the browser inside the app - in that case the ChildBrowser is not limited with the same cookie limitations.
I recently wrote a tutorial on how to make this work with Phonegap and Childbrowser for iOS.
Notice that this tutorial is on using OAuth 2.0 which is somewhat different from OAuth 1.0.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With