From Screws to Software: The Power of Standards

We are surrounded by standards, even if we don't realize it. A lot of different things, from cars and home appliances to electrical grids, screws and paper sheet sizes, are standardized. Standards make our life safer and allow for interoperability. For example, when you buy a screwdriver, you don't have to worry too much about which manufacturer produced the screws or whether the tool will fit.

The situation is similar with software. There are plenty of standards that regulate many aspects of software, like architecture, security features, data structures, flows, and interfaces. Some are created by professional standardization bodies like IETF, CNCF, or OpenID Foundation. Others, like the recent Model Context Protocol, are maintained by communities of dedicated practitioners.

The origin of the standard is not the most important factor. What matters is if it becomes widely adopted. Some standards are initially created by companies or communities, but once they gain popularity, they are taken over by professional bodies. 

This ensures quality and proper support for the standard. However, even though we have some popular and well-established standards in the IT ecosystem, I still meet people who are reluctant to follow them. I think there are two main reasons for this reluctance:

• perceived implementation difficulty

• illusion of vulnerability

Myth: Standards Are Hard To Implement

People sometimes look at a standard and think it is overcomplicated and hard to implement. While I'm not saying this is never the case (we developers sometimes have this innate ability to over-engineer), I think that more often than not, it is just a feeling.

For example, look at OAuth 2.0 and its authorization code flow. I had conversations about why the flow is so complicated, why the authorization server returns a temporary code instead of tokens, and how it only complicates things. 

In this case, the standard’s authors made design decisions to introduce better protections for the flow — the additional request to get tokens is there to better protect them. And when you distill the flow, it turns out that its implementation is pretty straightforward — an OAuth client needs to send a POST request, be able to receive a GET request (the authorization server's response sent through a redirect), and send another POST request. Sometimes, a standard might look complicated, but very often the decisions are well thought through, and we might just not know the details.

When we are consumers of standards, it is hard to know the reasoning behind every design decision, so we usually have to accept that the standard solves the issues in the best way. Very often, when we try to come up with a better and simpler solution than the standard proposes, we start small and build up to create the new solution, solving any issues as they arise. In the end we usually just come to the conclusion that, indeed, what the standard proposes helps solve the issue pretty well.

Myth: Standards Make Vulnerabilities More Dangerous

Another argument I heard against using standards, especially the popular security standards, are the vulnerabilities that inevitably show up in any software. If everyone is using OAuth, and someone finds a way to hack an OAuth flow, then everyone becomes vulnerable. In essence, this is true, but there is another side to this.

When you have a popular standard, you also have a group of maintainers that looks after it. If someone finds a vulnerability, then you have these experts who can quickly come up with a solution and propose an update to the standard.

To stick with the OAuth example, when people found out that in a mobile environment, an attacker can intercept the authorization code and steal tokens, they came up with PKCE. Because you are using a proprietary solution doesn’t mean you are automatically more secure — you don't have the community of experts that vet standards and can help with patching them. If someone hacks your proprietary solution, then you are on your own to patch it.

Yet, the support from maintainers is not the only reason why it is beneficial to follow standards.

Standards Facilitate Adoption and Innovation

Using standards makes it easier to adopt innovations and shorten the time to market.

For example, if you are using OpenAPI to define your APIs and implement standardized API error responses, it is then much easier for both internal and external integrators to consume your APIs. Internal teams can deliver products and features faster, while external developers are more willing to integrate with your API.

Another advantage is when new trends and technologies emerge. Like AI agents and Model Context Protocol, for example. The specification mandates the use of OAuth to secure the MCP server. This means that companies that already use OAuth will be able to implement MCP servers more easily and deliver them faster.

Companies that do not yet use the OAuth security standard to protect their applications and APIs will need much more time and effort to work with MCP. In this case, using one well-established standard makes it easier to integrate another.

Even when there are no novelties on the horizon, you still benefit from using standards. Popular standards spark community support, which makes your life easier.

Ecosystem Support

Popular standards gain organic support from the community. People create tools that facilitate working with standardized systems. For example, if you use OpenAPI, you can then utilize products that automatically create documentation pages or generate SDKs to integrate with your API.

Systems that use OAuth can be easily integrated with applications through the use of OAuth libraries. Without these standards, companies would have to build bespoke solutions every time they needed a feature.

When deciding to use a standard, you might not even know what its adoption will eventually enable. For example, in the space of AI agents and MCP, companies that already implemented GraphQL as a standard for APIs can now leverage solutions like Apollo's MCP server for GraphQL to set up an MCP server in no time. Again, using the standard, allowed for easier and quicker innovation thanks to tools provided by the community. This wouldn't be possible without implementing standards.

Always Use Standards

Whenever possible, utilize a standard for your architecture or implementation. Following standards is beneficial to your organization, even if it takes time to understand it and its ecosystem. You will quickly see the returns from such an investment — whether in support from the community with patches or tools, wider adoption of your product, or ease in onboarding new employees.

Standards make your solution future-ready, simplifying replacements, integrations and innovations. Bespoke solutions can rarely match these benefits.

At Curity we wholeheartedly believe in standards. We participate in the works of standards bodies like the OpenID foundation, and we make sure that our flagship product — the Curity Identity Server — follows as many of them as possible.