It seems you are talking about Canvas app and connected app.

then here is difference.

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. Thesession 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.

Hope this will help you.