API Security – How to send signed/encrypted payloads?
As part of co-operation with apidays conferences, and apidays Helsinki 2020, a joint online event was held in collaboration with Joint Research Centre of the European Commission on public and private sector co-design on API development.
After presentations by public sector organizations from around Europe, a panel discussion summarized and aimed to answer the questions coming from these public sector organizations.
Private sector seasoned API experts Alan Glickenhouse (IBM) and Marjukka Niinioja (Osaango, panel chairperson), as well as Lorenzino Vaccari (European Commission, JRC consultant) discussed API-related questions presented by the public sector speakers in part II as well as topics brought on by the audience.
Panel concentrated on questions related to lifecycle management, discoverability, API design and security.
Part 1 : How should you handle API change management?
Part 2 : What is the impact of distributed architecture to API lifecycle?
Part 3 : How to discover public and private-sector APIs?
Part 4 : Can we have APIs with different data models in the same marketplace?
API Security – how to send signed/encrypted payloads?
Questions for the panel:
- JWT is the current standard for sending signed/encrypted payloads in REST APIs, but all security experts point that it’s insecure; who’s working on a suitable replacement? A similar thread has recently been opened on X.509 client certificates.
- What other options would you recommend in order to establish server identity / server trust in addition to TLS?
Glickenhouse: Secure data is data that has been erased and written over at least 20 times. If data exists, it can be potentially accessed. The best approach is to use multiple techniques and layers of security, JWT is just one part of the security solution. Multiple security layers are the solution, starting from strategy and ending up to authentication and authorization. It’s even possible to use AI to detect abnormal patterns in the API usage.
Niinioja: In X-ROAD and eDelivery CEF building blocks use secure servers on both ends to secure the traffic, also the network layer. Messages are encrypted, using certificates and potentially token-based authentication. In X-ROAD, like we just heard in the previous talks, they encrypt the business information with the message. This means that even if you can access the API, it also ensures the immutability of the message.
Glickenhouse: It’s sometimes important to define who can even see the API, or know of its existence, or know about the implementation details of your backend.
Niinioja: In a public sector context, I would be very careful about what context we are talking about. There are military grade needs, where you need to think about who knows about your servers, are they located inside your country’s borders. You need to think about where your network traffic gets routed through. On the other hand, there is the “middle layer”, where very good security and privacy are enough. Sometimes, even in the public sector, consumer grade is good enough. If everything is expected to be designed with the same requirements, like I’ve seen done in some public sector cases, it’s going to become really expensive. Often the discussions revolve around “which cloud is a safe cloud” etc. But really, the use of JWT, in a token-based authentication architecture is usually good enough for the “middle layer” if done correctly. This is assuming you use HTTPS or in general secure protocols and you have valid certificates. The weakest link is usually the API authentication, because developers assume that an API is only going to be used on the server-side and by trusted parties, and use simple API keys, instead of token-based authentication. That is often not the case, because everything from a mobile application, single page application to any IoT device from cars to washing machines runs the code on the users device and the API and the API keys are therefore easily exposed, despite the encryption or network security. This is a very common problem also in the private sector right now, there have been a lot of leaks lately because of that.
Glickenhouse: There are great examples of this for example in the car industry a few years ago, when car manufacturers were creating apps to open the car doors etc. The problem was the user of the app was not always the owner of the car. So it’s a real issue that your interface might be stolen.
Niinioja: You need to also implement the token-based authentication correctly for it to be secure. You also need to use OpenID Connect instead of, for example, Oauth 2, there is a clear difference in terms of security. SAML for example is even less secure than Oauth 2,I came across a research on this when writing the “API Economy 101”. Then there are implementation details like introspection when you really want to make sure your API management helps you to secure your APIs and only the valid tokens are passed on by the API management to the backend, especially when using microservices. Also the services should be implemented correctly to decrypt the token and use the identity information to decide which data and operations the users are authorized to use.
Vaccari: Important thing to add is that while no information should be accessed without authorization, it is equally important to check how standalone published data can be combined to deduct sensitive information. The privacy aspects are the main consideration of the European Commission in this field. Sometimes with open data we had issues with this, because, for example, it is not always possible for a unique data provider to check all the possible ways datasets coming from different data providers can be combined and analysed with big data techniques to extract meaningful information. Sharing a harmless looking dataset combined with a totally unexpected set of data suddenly exposed combinations that were not intended. These could not have been detected by humans, but for artificial intelligence there are easy. We have to pay attention to the design of APIs, so that we share the information and data models related to it in the right way. On the other hand, filtering and tuning the publication of datasets via APIs, instead publishing them for a bulk download helps a lot sharing the datasets in the right way and reducing the risk of extracting sensitive information.
Niinioja: Important detail to remember is that the information that might be accidentally shared might be in the headers and not the body. Because of this, for example audit logs might expose interesting things, even though the request bodies would not be logged.
Even though we didn’t have a chance to discuss these in the panel, there are potentially better alternatives to JWT tokens, such as biscuits, macaroons and brancas. All have different flavours and optimal usage scenarios.
