Adding layers of security to an API in real-time

Editor's Notes

• #5: OAuth2.0 icon: jlabusch.github.io/oauth2-server “End-to-end trust” mTLS: OAuth: client has to provide a token (called access token) that again serves as proof of the client’s identity. So first of all, that access token helps to determine whether this particular client is allowed access to the API at all. In addition, more fine-grained authorization may be in place, allowing one client to access an API resource whereas another client is denied that access. (with open banking: Payment APIs accessible to “payment clients”, and Account APIs accessible to “account clients”. OAuth: security that pertains to the relationship between a particular client and a particular API version. So now you know that whatever message you are receiving, it is actually coming from that particular consumer (and may have been consented by the resource owner). Still, you’d like to have some proof that a particular message is actually coming from that sender (client). Hence, signing the message. In particular relevant when it comes to non-repudiation (and also for ‘future reference’ – the message may be stored in its tokenized form, for audit purposes). Once received by the API, the message may be decoded and sent to the downstream system that it’s meant for. Or the message may be forwarded in its encoded form. Or it may be decoded and encoded again – using a very different technology perhaps (greatly depends on what the downstream system can handle). And, by the way, the whole story may repeat itself on the way back. NOTE that by having the client sign the JWT with its certificate, you explicitly associate that client with that certificate (which is on a more ‘profound’ level than doing so just on the transport level??) So full-blown, it COULD look like this: A client establishes a mTLS-secured connection with an AS to request an access token (and, possibly, an ID token); Alternatively, the client may use a JWT assertion for authentication purposes; If using JWT access tokens, the client will receive a JWS that is signed by the AS; the client can verify the JWT using the public key; The client may then proceed to establish a mTLS-secured connection with the API endpoint. It may use the same client cert, or a distinct one; The client forwards the access token (JWS) to the API gateway, typically in the request Authorization header. The gateway validates the token (public key) and authorizes the client (yes, this client may access this API resource)] The request sent by the client contains another header that contains another JWS/JWE, which represents the signed request payload. This JWT may have been signed by the client cert used to establishe the TLS connection – or yet another one. The API gateway validates the incoming JWS and, if ok, accepts the request.So, all in all, several private/public keys may be used, and multiple JWT may come into play (ID token, access token, message payload).
• #8: Good as it all is – we’re not quite there yet. Even though the client may be acknowledged as a trusted one, and even though we are certain that the received message is coming from that client (as proven through the JWT signature) – we can never be sure of the intentions of the user. Even a signed and encrypted message may contain malicious content, for example. So that’s yet another thing that needs to be validated.