Adding layers of security to an API in real-time
•
3 likes•406 views
A workshop presented at APIdays Paris.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Adding layers of security to an API in real-time
Similar to Adding layers of security to an API in real-time (20)
More from Rogue Wave Software
More from Rogue Wave Software (20)
Recently uploaded
Recently uploaded (20)
Adding layers of security to an API in real-time
- 1. 1© 2018 Rogue Wave Software, Inc. All Rights Reserved.
- 2. 2© 2018 Rogue Wave Software, Inc. All Rights Reserved. API Security Layers Transport layer Client authentication and authorization Content security
- 3. 3© 2018 Rogue Wave Software, Inc. All Rights Reserved. In summary… • mTLS: ensures client authenticity • OAuth: ensures client authorization • JWT: ensures message integrity, confidentiality, and non-repudiation. Ensure that each request is coming from a trusted source
- 4. 5© 2018 Rogue Wave Software, Inc. All Rights Reserved. Add layers of security to an API - let’s see it for real!
- 5. 6© 2018 Rogue Wave Software, Inc. All Rights Reserved. Demo overview • API: open banking Accounts-and-Transactions – Apply mutual TLS – Apply Oauth2.0 – Apply JOSE Security / Open Banking security – Apply additional message security
- 6. 7© 2018 Rogue Wave Software, Inc. All Rights Reserved. Additional security aspects to consider • MFA (SCA) User authentication: can we trust the user? • Injection • Cross-site scripting • Request overload • … Can we trust what the user is doing?
- 7. 8© 2018 Rogue Wave Software, Inc. All Rights Reserved. Conclusion API security: There’s quite a lot to it …but there’s useful specifications to help you out. Implementing security standards is far from trivial …don’t do it yourself …excellent tools in the market to help you
- 8. 9© 2018 Rogue Wave Software, Inc. All Rights Reserved.
- 9. 10© 2018 Rogue Wave Software, Inc. All Rights Reserved.
Editor's Notes
- 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).
- 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.