Clients gain authorisation to use our API by using a technical standard called "OAuth" specifically the client credentials workflow (https://www.oauth.com/oauth2-servers/access-tokens/client-credentials/). The way this works is by requesting "access tokens" that applications can then use to access the API. These tokens can be shared with people and systems without giving away the credentials used to create them.

Tokens expire after 10 minutes to safeguard the data provided by the APIs to authorised applications only.


Why do these tokens expire?

API keys and username/passwords are similar, but crucially, tokens are designed to be able to be safely shared, where passwords are not. They do however have a lot of similarities and have a shared set of risks around leaks and theft.

  • Leaked tokens are a security issue like any other leaked credential. If a developer has their API key stored on their machine, build machines or personal accounts and their system or account is compromised, it is trivial for an attacker to take advantage of this leak and re-use the developers credentials. While some leaks are exploited immediately, many attackers hold on to keys until the circumstances are right to exploit for maximum gain.

  • Stale tokens occur where a valid security token exists longer than the authorised credentials used to create it. As authorised users leave organisations, their accounts can become dormant. Accounts tied to these tokens are often either deleted or unmonitored and so attackers can access API functionality undetected.

Only allowing tokens to remain valid for a short length of time is a universally accepted practice to minimise both of these threats, and specifically where personal or other sensitive information is involved, helps to enforce compliance with GDPR and similar Data Protection regimes.


What do I need to do to manage tokens?

As tokens for our API expire every 10 minutes, if you need to use them in line-of-business analytics applications you will need to put in place an appropriate strategy to manage these tokens.

As an example, many people use analytics tools, such as Excel, PowerBI and Tableau to visualise their data.

Both Tableau and Microsoft PowerBI support access to APIs. However out-the-box, they are limited to APIs that are either:

  • On premise and authenticate using NTFS permissions, or;

  • Are publicly available on the web and so require either no authentication or basic key authentication.

If you are using analytics tools to regularly query OAuth based APIs (or any other scheme with expiring tokens), such as the Firefish API you will need to develop an appropriate integration method to access the data you need. It's worth noting that all of these require some software development expertise.

Some methods to consider are:

  1. Building a Custom Application
    OAuth and REST-style web APIs are supported by a huge range of software developement platforms and you can use these to build Firefish data in to custom applications such as websites, mobile and desktop applications. If you are looking for a bespoke solution optmised for your own workflow, this may be your best value option.

  2. Extending your chosen Analytics Tool
    Many analytics platforms such as Power BI and Excel offer either a "Software Development Kit" or SDK, or a built in scripting language which you can use to build a connector or plug-in. You can use this to manage access to the API, and where you have one or two expert users accessing the API, this may be your best option.

  3. Building a Data Warehouse (or other intermediate storage) integration
    If you have separate IT and analytics expertise in your organisation, you may find it preferable to create an application (or other data orchestration tool) to import data in to an intermediate source. This intermediate source can then be used in your Analytics tool of choice. This can offer benefits in terms of centralising data import and management of credentials and means that your Data Analysts do not require any programming knowledge.

Whatever method chosen will need to carefully consider the unique security requirements of the application. As you can see, there are many options for this and one of the reasons Firefish selected OAuth as an authentication mechanism is that it supports a wide variety of platforms that can be used to integrate data in to various applications (https://oauth.net/code/).

Did this answer your question?