From WS-Security to API Message Security?

API Management – and application integration in general – go hand in hand with good security practices. It is crucial to protect the message exchanges between all the systems we link together. This article focuses on the integrity of API requests and responses. Where we still lack a broadly accepted approach or standard.

From XML Signature to WS-Security

The XML spec (1998) was created with a lot of related specifications such as XPath (1999). On the security side, XML Signature (2002) and XML Encryption were rapidly available. These standards were the foundation for WS-Security, with it’s most relevant use case, the X509 Token Profile (2004).

XML Signatures have some great features:

  • Embedded within the XML document itself (detached also supported)
  • Normalization of the message before calculating the hash, the “canonicalization” or C14N
  • Specific parts of the XML message can be signed
  • Multiple signatures of parts of single XML document

BTW, best book ever on WS-Security and related remains “Securing Web Services with WS-Security: Demystifying WS-Security, WS-Policy, SAML, XML Signature, and XML Encryption”.

JSON Message Level Security

On the JSON side, we have the JSON Web Signature (JWS) spec (RFC7515, 2015). JWS is the basis for JSON Web Tokens (RFC7519). Although a JSON canonicalization standard exists – albeit not very popular – with JSON Canonicalization Scheme (RFC8785), the JWT spec opted to base64 encode the message, turning JSON into non-JSON.

JWT or jot tokens are well supported and very useful for JWT tokens, e.g. the identity tokens of OpenID Connect.

API Message Level Security?

In the API world, SSL/TLS is the foundation for secure exchange of information. There is no tendency whatsoever to apply protection on the request or response level. A bit weird, where 15+ years ago we went through great lengths to protect XML messages while going over multiple network hops. In the API world, we seem to believe that there is only a single network hop between client app and back-end API? No API Management or other components along the road? 

There is no standard (approach) yet to provide message level protection of our API requests and responses. Where “message body” is the resource representation of and API responses or the request body with HTTP POST, PUT or PATCH verbs.

The draft HTTP signatures RFC is an important step for message level API security. Where HTTP headers are being signed. And where the body can be included in that signature by adding the hash of the body as a Digest header cf. RFC3230

The Signing HTTP RFC has difficulty getting “finished”. The “old” Signing HTTP Messages draft RFC is now being succeeded by the new draft Signing HTTP Messages RFC. A lot of topics for discussion remain. With an important one missing: reference to JWKS or X509 client certs (x5c) for signature verification.

Where is the “API Security” spec?

But where is the overarching approach? Where HTTP signing includes the message body, with canonicalization based on the content-type: JSON C14N, XML C14N or other? Where is the successor of WS-Security in the API world?

And as a nice extra: where is the successor of Web Services Security X.509 Certificate Token Profile so we can continue using X509 client certs as alternative for JWKS?

Author: Guy Crets

Guy Crets

Guy Crets

Curious to know more about this topic?

Working at i8c

i8c is a system integrator that strives for an informal atmosphere between its employees, who have an average age of approx 30 years old. We invest a lot of effort in the professional development of each individual, through a direct connection between the consultants and the management (no multiple layers of middle management). We are based in Kontich, near Antwerp, but our customers are mainly located in the triangle Ghent-Antwerp-Brussels and belong to the top 500 companies in Belgium (Securex, Electrabel, UCB, etc…).

Quality Assurance

i8c is committed to delivering quality services and providing customer satisfaction. That’s why we invested in the introduction of a Quality Management System, which resulted in our ISO9001:2000 certification. This guarantees that we will meet your expectations, as a reliable, efficient and mature partner for your SOA & integration projects.

i8c - ISO9001-2015

Also worth reading

Apigee Scope Validation using OpenAPI Specification

In API security and management, we often use a lot of different security mechanisms to protect the requested resource behind the API Gateway. One of these mechanisms is the validation of scopes to authorize a client on a specific sub-resource of the API. Most of

Read More »

Integrating with TIBCO CLOUD

Our experts Glenn, Jason, Jurgen, and Kevin dedicated an i8c FastTrack Day to examining the TIBCO iPaaS offering. Check out their Research & Development day report to learn what they uncovered. 👇  TIBCO CLOUD™ The TIBCO Cloud™ Integration enterprise integration platform-as-a-service (iPaaS) provides self-service integration

Read More »