Fire Eagle : Choosing which type of Auth to use

When you first 'create a new application' on the Fire Eagle site, you will be asked to choose between web-based, mobile, desktop or plugin authentication. The choice you make determines the way that user-specific access tokens are exchanged. It also impacts the user-experience.

The form of authentication dictates which API methods your application will be able to perform. Applications on any platform can query or update an individual user's location (as long as the user has given permission), but only web-based ones can perform batch queries.

Web applications

For web sites and services, web-based authentication is almost always the best approach. The user-experience here is simple. They are sent from your service to an authorization page on the Fire Eagle site. Here they can set their preferences. When they confirm their choices they are then sent back to a page on your site. All the token exchanges happen behind the scenes.

Because web-based applications commonly manage multiple users from a single instance of the application (unlike a mobile or a desktop application), applications that auth in this way are able to perform certain batch queries. They do so by using a General Purpose access token.

For these sites and services, you'll need to maintain your own mapping between the user tokens in Fire Eagle and user identities in your own application.

If you are considering making a mobile social application, we recommend that you create a central web-based service that interacts with Fire Eagle and then manage the relationship between that service and your users' mobile devices yourself. For the sake of user security, we do not allow mobile applications to directly query or update multiple user's locations.

Mobile applications

Mobile authentication is the best solution when the application is locally installed as a client application and is not able to easily trigger a web browser. These applications should only support one user per application instance (ie. they can only query and update one user's location). They do not receive a General Purpose Access token and so cannot perform any batch operations.

In this case, halfway through the authentication process a user is required to visit a web page, either on the same device or on a nearby computer. On that page they must enter a code displayed by the mobile application. Then they need to inform their local application that they have performed the authorization before the app can talk to Fire Eagle.

This form of authentication is ideal for many older mobile devices. It's particularly good for creating applications that update a user's location or locally use their location in some way. It is not good for creating mobile social applications as it does not allow you to find the locations of multiple users. If you want to create a mobile social application then we recommend that you build a web-based service and then independently manage how that service engages with the mobile device.

Desktop applications

Desktop authentication is a bit of a misnomer as it's also the ideal form of authentication for applications installed on modern mobile devices such as the iPhone, as well as on standard home or laptop computers. In fact it's good for any application that can easily get access to the Internet and can trigger a web browser.

In this form of authentication, a web browser is launched and goes to the authentication page where the user is asked to set their preferences. Once they have done so, they must tell their local application that they have done so. Once that has been completed the app can talk to Fire Eagle. The user does not need to type in a code.

In other ways, this form of authentication is identical to standard mobile authentication. It's good for updating a user's location or locally using their location in some way. It is not good for creating mobile social applications as it is not allowed to access or update the locations of multiple users. Applications authorized via the desktop auth do not receive a General Purpose Access token. If you want to create a mobile social application, then we again recommend that you build a web-based service and then independently manage how that service engages with the mobile device.

Plugins

Plugin authentication is intended to be used by application plugins, such as WordPress, MovableType or Drupal plugins. These are usually live on the internet, but they differ from web applications in that they can be installed by multiple, unrelated people. As such, the range of API calls they have access to is limited, as recent and within would reveal Access Tokens that are not known by the local installation of the plugin.

In this form of authentication, a web browser is launched and goes to the authentication page where the user is asked to set their preferences. Once they have done so, they must tell their local application that they have done so. Once that has been completed the app can talk to Fire Eagle. The user does not need to type in a code.

With the exception of API availability, this form of authentication is identical to standard web authentication. It's good for updating a user's location or locally using their location in some way. It is not good for creating social applications as it is not allowed to access or update the locations of multiple users. Applications authorized via the plugin auth do not receive a General Purpose Access token.