What's the practical difference between canvas & connected apps?

Canvas App

Canvas apps are designed to the part of the user interface. Either the app is designed to appear to be native to salesforce.com, like a Visualforce page, or is intended to be accessed through salesforce.com, such as legacy cloud apps. Authentication for a canvas app is server-initiated and controlled by profiles and permission settings. The app cannot be accessed outside salesforce.com unless it provides an alternative login mechanism. The session lifespan is only as long as the user is logged in to the user interface. The app has full access to the user's data, just as any normal API-style application. The app must be cloud-based. Access is automatically granted.

Connected App

Connected apps are designed to be run independently of the user interface. Either the app is hosted on an external website that interfaces with salesforce.com, or is a desktop or mobile app that runs on a client. Authenication for a connected app is client-initiated and must be done per-client. Connected apps are usually accessed outside salesforce.com, although this is not a stringent requirement. The session lifespan may be indefinite until revoked by the user or an administrator. the app has limited access to the user's data (referred to as the scope), which may be as minimal as identity confirmation only up to full access. The app may be run on a server or client. Access must be manually granted.

Examples

Canvas apps excel at providing services that are accessed through the user interface of salesforce.com. For example, a service that provides salesforce.com users the ability to send mass emails could be implemented as a canvas app. The app doesn't need to be run when the user is not log in, and doesn't have any meaningful context outside salesforce.com. The app doesn't request a username, password, or security token, because the authentication is initiated by the server. From the user's perspective, the integration is seamless, and they may not even be aware that they are running an application on a third-party server. This design model is identical to API-enabled programs that are accessed through a web tab by providing a session ID; this mechanism is meant to replace that model of logging in. It has better security because the administrator can control access per-profile, while the old model only permitted either all-or-none access to any API via the "API Enabled" permission. Note that the API must still be enabled, but even when enabled, if a user doesn't have access to the app, they won't be able to access it.

Connected apps, on the other hand, are intended to be accessed outside of salesforce.com. While there are still profile- and permission set-level controls, an initial authorization still has to occur. Depending on the app, the user may need to provide a username, password, and security token, although the "web flow" can still be used to obtain a token. Unlike a canvas app, this app now has access to the system for as long as the access token remains valid. This could be days, weeks, months, years, forever. Each individual client has its own authorization token, and this token can be revoked as necessary. For example, an instant messaging system that leverages salesforce.com's Chatter would be a connected app. If the device is lost or stolen, the authentication token can be revoked, removing that client's ability to use the system. Since the username, password, and token are not stored by the client, there is no way the device could access salesforce.com data once the authenication token is revoked. Login is not seamless, though, so one wouldn't ordinarily want to simply place a connected app in a web tab, since the user would have to grant access.

Questions

Generally speaking, there are a few pertinent questions that will decide which mode of access you want to use:

• Should the app appear in the UI? (yes: canvas, no: connnected)
• Does the app need long-lived access to the system? (yes: connected, no: canvas)
• Does the app run on a client? (yes: connected, no: connected/canvas)
• Should the apps access be limited by scope? (yes: connected, no: connected/canvas)
• Can the app be lost or otherwise physically compromised? (yes: connected, no: canvas)
• Does the app provide functionality outside salesforce? (yes: connected, no: canvas)

Common Examples

These examples are just like other popular APIs out there, such as Facebook or so-called "social APIs".

• A news website that lets you Chatter about articles: connected
• A mass emailer app that lets you email from a variety of mailing lists: connected
• A website that lets you log in to your account through salesforce.com: connected
• A desktop data loader application: connected
• A blog that Chatters about new articles and comments: connected
• A custom calendar that appears in salesforce.com and pulls data from other sources: canvas
• A mass emailer that can only be used with salesforce.com: canvas
• A legacy application an enterprise uses that needs to be exposed through salesforce.com's UI: canvas
• A data cleansing tool that runs inside salesforce.com: canvas
• A bug tracker app that appears inside the salesforce.com UI: canvas

Synonyms

A canvas app is an "embedded app," similar to older applications that accepted a session ID in order to use, classically like a S-Control tab, but with better permission control.

A connected app is an "API app," similar to older applications that used a username and password to obtain a session ID in order to use, but can be revoked from the system, have a longer session lifespan than a session ID, and have fine-tuned controls to limit access as necessary.

Practically, canvas apps are accessible inside salesforce and can be build using any language of your choice. By this, I mean we can interact with salesforce from a external application, but within salesfore and with an interactive UI. Canvas don't work in offline mode as they have an UI, but connected apps can access data from salesforce even if user is offline and performs various operations on behalf of the user. Connected apps are used in integration which can control salesforce organization on behalf of it. They are just authorizing gateway for app administrator to app user.

I want to explain this in a different way. Some of the difference between the two is lying within the settings for canvas app as below. As soon as you click that little checkbox called 'Canvas' within connected app, all of canvas app framework features activated automatically, and some can be configured through below settings.

BTW, canvas app is also a kind of connected app. You can consider canvas app as connected app with some enhanced features to make it work seamlessly with external apps within Salesforce UI. Some of these additional features are:

1. As you can see, canvas app settings has 'Access Method' option which simplifies the way your connected app is getting authenticated and authorized. This is important when you want to have your canvas app do authentication and authorization behind the scene without having user know about it.
2. Canvas app framework provides Lightweight and easy-to-use JavaScript libraries.
3. Canvas app framework natively provides 'Context Services' which tells more about the logged-in user, what org are they in, how much area does the canvas provide to display etc.
4. It natively allows cross-domain API calls.
5. It is based on lightweight JSON eventing framework which allows your apps to publish and subscribe to events. (the events are sent through Canvas API).

So, in summary, above said additional features on top of connected app makes a canvas app.