Networking 2.0: Security and Privacy

In the world of software development, APIs have become ubiquitous, enabling communication between different applications and services. While traditional APIs rely on TCP/IP networks for communication, a better approach–Networking 2.0–is emerging that leverages a network with inherent identity. This paradigm shift simplifies API development and security.

The Outdated Way

In the current world, APIs typically follow a client-server model, where a “client” sends requests to a “server,” and then maybe that server responds. This Networking 1.0 communication relies on TCP/IP networks, where messages are transmitted without any inherent identity associated with them. 

As a result, API developers face several challenges:

• Authentication: API tokens and other mechanisms are required to verify the identity of the sender.
• Security: APIs must be exposed to the Internet, making them vulnerable to DDoS attacks.
• Infrastructure: API owners need to invest in infrastructure to handle DDoS attacks and manage API traffic, which is time-consuming and expensive.

A Better Way

Networking 2.0 introduces a new approach to API communication by introducing an identity layer on top of a network. This means that every message sent or received is associated with a network identity (in Atsign’s implementation, we call it an, “atSign” i.e @alice, or @bob). This identity-based networking provides several benefits:

• Simplified Authentication: API developers no longer need to worry about complex authentication mechanisms. Instead, they can simply manage which network addresses or, “atSigns” are authorized to access their APIs.
• Enhanced Security: APIs do not need to be directly exposed to the Internet, reducing the risk of DDoS and other malicious attacks. Instead, in our implementation, communication is forwarded outbound through “atServers,” right on the edge of the network.
• Reduced Infrastructure Costs: API owners no longer need to invest in costly DDoS infrastructure. In Atsign’s implementation, atServers handle DDoS protection, reducing the burden on API owners.

Shifting the API Perspective

The shift to identity-based networking with Networking 2.0 has significant implications for API development:

• Focus on Authorization: API developers can focus on defining authorization rules for atSigns/network addresses, rather than managing authentication tokens and other mechanisms. The atProtocol allows atSigns to set an allowLists (or a blockList) on their atServer. For example, an API’s atServer could have a rule-set that only allows @alice and @bob to have authorization, automatically rejecting any other requests from other addresses. 
• Reduced Security Concerns: API exposure is minimized, reducing the risk of cyberattacks.
• Optimized Infrastructure: API owners can focus on the things they want to actually focus on, their internal app development, while atServers handle network communication and security.

Moving Forward

Identity-based networking with Networking 2.0 represents a paradigm shift in API development, offering simplified authentication, enhanced security, and reduced infrastructure costs. By leveraging the power of identity, API developers can focus on building secure and scalable APIs that drive innovation and collaboration.

For more information, read this recent post about Networking 2.0 vs. APIs, featuring a demo by Atsign CTO and Co-founder, Colin Constable.