TOWARD INCREASINGLY DECENTRALIZED iss…
In recent years, companies have faced an expansion in the scope of Identity and Access Management (IAM) activities. They no longer concentrate solely on user provisioning and authentication; focus has shifted toward both account review and certification and the use of identity federation mechanisms (for example, SAML). The changes affect both SaaS and those that remain in-house. These two developments mean that ISs have an ever-broader scope—and it’s vital that they are implemented properly to minimize security vulnerabilities.
These developments in IAM are running in parallel with more widespread use of cloud services, which are continually being used in new ways to increase the scope and flexibility of IS access and use. Internal users accessing an IS are increasingly doing so from outside the corporate network—and from an increasingly diverse range of devices.
In addition, new Agile and DevOps technologies are forcing ISs to evolve in a different direction: integrating new technologies (IoT, etc.) and new uses, much more rapidly.
Today, all these developments make an IS one “bubble” among others, interacting with its environment and remotely controlling interactions between decentralized components.
…MAKING APIs ESSENTIAL
This new, decentralized IS model raises the problem of the interconnection of services and applications: How can you ensure a controlled access to data at all times—and in all places?
Today, APIs are already a predominant and essential communication mechanism for any company embracing digital transformation. They are used to process not only public data (branch addresses, transport timetables, etc.) but also personal data (for example, fitness tracker, health insurance, and government benefits apps) and sensitive data (online payments, e-commerce, mobile industrial information, etc.).
And, given their importance to ISs, the challenge of securing APIs becomes more important than ever.
WHAT’S THE RIGHT RECIPE TO SECURE YOUR APIs?
Securing APIs requires a recipe based on four ingredients, all of which must be carefully measured out.
THE SECURITY AS USUAL BASELINE
In a Wavestone benchmarking exercise on web application security, of the 128 applications we audited, serious flaws were observed in 60%. In this respect, and since APIs are just a kind of web applications, the standard web-security recommendations – for example those for OWASP – Open Web Application Security Project, must be taken into account in just the same way.
Essentially, this ensures that a web application’s main areas of risk are covered, and the appropriate security measures determined.
A pinch of OAuth
OAuth is an authorization delegation framework that allows an application to obtain permission to access a resource on behalf of a user.
OAuth2 is designed to cover a wide range of use cases (web applications, mobile, access [or not] via a browser, server-to-server access, etc.), and, to this end, it offers four main process flows to obtain a token (RFC 6749). Together combined with a specification detailing the use of this token (RFC 6750), a document detailing the threat model (RFC 6819), and a dedicated authentication overlay (OpenID Connect), results in a body of documents that runs to some 250 pages, leaving room for a broad range of implementation options and choices.
What’s more, it’s this abundance of options—and lack of constraints—that lead to the security flaws regularly observed in the implementation of OAuth2.0: the misuse of an application, access to personal data of a third-party user, the theft of Facebook/Google cookies when logging in using social media, or the compromise of a user’s account.
The following six recommendations are essential in ensuring the framework is securely implemented:
- Local storage of secret information: The client application is provided with identifiers enabling it to authenticate itself with the OAuth server; so, don’t put this secret information (the service identifier) in the mobile application; and, if you do, consider it compromised
- Redirected URLs: Validate redirected URLs strictly with the application, without the use of wildcards
- Implicit: Avoid implicit grant as far as possible (and strictly reserve it to client-side javascript applications)
- Authorization codes: Validate authorization codes strictly, as well as the associated clients
- State and PKCE: Use these to ensure the integrity of the entire series of process steps
- Authorization ≠ Authentication: Use OpenID Connect to authenticate, but OAuth to delegate access
LIMIT THE ADDITIVES
As soon as this first pinch of OAuth has been swallowed, you need to start thinking about the security measures to meet the most frequent needs.
The Single Sign-On mobile… or, how to enable mobile employees or clients to easily access multiple applications without reauthenticating?
It might be a field agent in a customer-facing role, or making a series of interventions at different sites, all while using a good dozen of applications every day; or it might be a client who’s installed several applications on the public app store and needs to access them all, without having to reauthenticate on each… Today, these are all very common scenarios. Although, since 2008, the techniques that make it possible have varied depending on the possibilities offered by the mobile OS (iOS’s KeyChain, URL parameters, Mobile Device Management, etc.), Apple and Google converged toward a common solution in 2015: the use of the browser system as an anchor point for an SSO session. This is now officially good practice, formalized in “Best Current Practice – OAuth2 for native applications.”
Contextual authentication… or, how to match the access level to the data, according to its criticality
One of the many issues concerning authentication is to simplify, as much as possible, user access to data, while still guaranteeing satisfactory levels of security. Contextual authentication provides an answer to this issue, adapting the level of access to the nature of the transaction: its characteristics, user habits, context, and so on. This is termed LOA (Level of Assurance). A mobile banking application, for example, allows the user to access their bank account, and see account balances, without having to reauthenticate each time these are accessed. However, the application will require authentication when performing a sensitive operation (transferring money between their own accounts, for example), and strong authentication when performing a very sensitive operation (adding an external recipient for a transfer, for example).
The market now offers solutions designed according to a logic where the application client is responsible for initiating the LOA request that corresponds to the data or service it requires. But the real need is to define and apply these data access policies at a single point within the authorization server. This is essential when there’s a need to apply an authentication proportionate to the level of risk (geolocation, is it a known terminal or not, transaction habits, etc.).
Identity propagation… or, how to pass an access token between two (or more) applications.
It is increasingly common that a call to an API triggers a cascade of calls to other APIs, in particular within a micro-service-type architecture setting. The transmission of the identity of the user must then be assured while still maintaining security. And the first three solutions that come to mind have limitations:
- The transmission of the initial token is obviously to be avoided, in view of the very high risk of internal fraud involved.
- Caller authentication alone is not enough either, because a compromised link in the chain can result in the theft of any user’s identity, thus compromising the rest of the chain.
- The generation of a caller token, transmitted along with the initial user’s token, does not assure the integrity of the user/API combination, and does not validate the chain.
However, an advanced initial solution does currently exist, in the form of a new grant type: Token Exchange. This mechanism allows the caller to request an intermediate token, which includes the identity of the user, the caller, and the call chain already made. This new series of process steps makes it possible to centralize the calls policy between micro-services, as well as its application, thereby ensuring the traceability of calls.
Protecting against token theft… or, how to guard against the theft of a token base?
As a rule, the token contains a good deal of information about its holder, entailing significant risks if stolen. More striking still is the fact that, in some contexts (for example, new standards on electronic payments such as those in the modified European Payment Services Directive [PSD2]), a third party (aggregator) may be in possession of many tokens, and the owner of the API is then effectively at the mercy of this third party and its level of security. Because theft is very difficult to detect, there was a need to find other solutions such as Token Binding: a negotiation mechanism using two or three components to link a token to a pair of cryptographic keys, and where the client must prove that it owns the private key that makes up part of this pair by establishing a mutual TLS connection with the API.
WRITING THE RECIPE DOWN
What’s the last ingredient of the recipe? The need to set out a reference architecture for OAuth in order to adapt it to the context of the company’s IS. To do this, the API framework must be defined, by:
- Defining and sharing the security rules: The authorized process steps and the application framework, the security checklists, and the reference architecture must all be formalized.
- Training and equipping developers: There will be a need to organize training sessions, and presentations on the principles to adopt. Project teams can be made autonomous in terms of their integration with the rest of the IS.
- Integrating security resources into Agile sprints: The resources that act as a “security coach” must be identified in order to support the application design, provide ready-to-use solutions, and serve as an accelerator.
IN SUMMARY
In summary, rather like the recipe for a good soup, securing APIs requires a list of ingredients, ranging from the most basic to the most sophisticated, while keeping the needs and context firmly in mind.
