Parables often discuss our inability to see, even though we have the faculties to do so. Modern day data security management practices adopt the same notion — we all have dreaded blind spots from mounting enterprise security needs. Let's move some of these blind spots a little further down the road.
In today's world of security technology, the well-known principles of identification, authentication, and authorization hold true. The principles have been implemented in protocols, operating systems, directories, and in applications for many decades. However, these decades-old principles directly contrast with what is going on with REST API's, Web technologies, and the blending of APIs across applications, topologies, and organizations.
This new age of API integration requires security practitioners to search for pragmatic technical solutions through Request For Comment (RFC) analysis, internal proof of concepts, open source initiatives, and the adoption of commercial products. Within these expanding choices you can also find surprising alternatives; for example, Blockchain technology. Adopting Blockchain technology as an API security measure is a new way of thinking and something many haven't explored yet.
Most people know Blockchain as the famed digital ledger system in which transactions made in Bitcoin or another cryptocurrency are chronologically and publicly recorded. This identity is changing and evolving quickly, and Blockchain may have found a calling as a security solution for API integrations. Can Blockchain help secure API integrations? Let's dig a little deeper into the technology and see.
Blockchain has a distributed database with data replicated across many nodes and little to no privacy when it comes to data elements. The database (ledger) system is implemented with hashed b-trees, also known as Merkle Trees. The ledger is immutable. Blockchain can be public, private, or hybrid. An interesting feature is the notion of a miner, for what I describe loosely as a system verification mechanism driven by consensus across nodes. Blockchain has a complex math challenge, which you need to solve to get a key to post to the distributed ledger. This is a lot to process.
Right about now, security engineers ask, "Where is my HTTP Verb, URL, JSON body, API Key, or authorization header?" "Where is my trusted domain where I can authenticate a user or a proxy?" "How do I generate a token to present to an application for authentication and authorization?"
Here is your first opportunity to cover a blind spot: The technical implementation of Blockchain doesn't secure APIs.
Blockchain requires a form of digital identity that is required to post the ledger. The Blockchain transactions are identified by a hashed value. You simply apply the SHA2 hashing routine to a transaction owner's public key to create the hash. For security engineers, this is a very straightforward practice. An interesting idea, the identity of the user that created the transaction could be masked into a virtual identity, an abstracted virtual pool of hashed public keys. If Blockchain applications map virtual identities, you could create a trusted community of users.
Here is your second opportunity to cover a blind spot: Blockchain requires a form of digital identity, which does not inhibit applications to create an abstracted virtual digital identity.
Knowing you could create virtual communities of users, public or private, allows you to think big about API security. Blockchain could potentially provide both identification services and, with some additional semantic, the notion of authentication services. If you could map a virtual pool of identities to Blockchain transactions, and apply an out-of-band mechanism to ensure authentication, you could generate lightweight tokens for REST API use. The tokens generated ideally provide identity, authentication, and role authorization like a Java Web Token.
Simply stated, for REST API's you need a security guarantee, such as a token. Blockchain could allow practitioners to group users and verify identity, and then you could generate a token for API use. Remember, you're thinking big and leaving some complex details out of this abstract model.
Security Reality Check
The ever-present problem is that Blockchain has no notion of authorization. Again, returning back to the basics, Blockchain doesn't secure API's. However, API security has potential and probably a team is out there somewhere in the Blockchain world working on applications and products to help the Web API practitioners. For now, we watch the market and wait.
There is much work to do and the Blockchain community continues to change, expand, and adapt. The future is unpredictable, but if you think big, you could adapt Blockchain to support a secured trust model and eventually lead to secured REST APIs.