apidays Paris 2024 - Military-Grade Security for APIs, Michał Trojanowski, Curity

Military-Grade Security for APIs
Michał Trojanowski, Product Marketing Engineer at Curity

apidays Paris 2024 - The Future API Stack for Mass Innovation
December 3 - 5, 2024

------

Check out our conferences at https://www.apidays.global/

Do you want to sponsor or talk at one of our conferences?
https://apidays.typeform.com/to/ILJeAaV8

Learn more on APIscene, the global media made by the community for the community:
https://www.apiscene.io

Explore the API ecosystem with the API Landscape:
https://apilandscape.apiscene.io/

Transcript

1. Military-Grade Security for APIs Michał Trojanowski Product Marketing Engineer @Curity mtrojan@mastodon.social
2. Who needs secure APIs?
3. Medical Finance Sensitive data
4. How we achieve security?
5. Make life harder for the attacker
6. FAPI
7. mTLS
8. TLS Client Server
9. mTLS = mutual TLS Client Server
10. Sender-constrained Tokens
11. Sender-constrained Tokens Bearer tokens Sender-constrained tokens / Proof-of-Possession tokens
12. Bearer tokens Client 2 API API Gateway Client 1
13. Sender-constrained tokens Client 2 API API Gateway Client 1 Client 3
14. Sender-constrained Tokens in OAuth • OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens — RFC 8705 • OAuth 2.0 Demonstrating Proof of Possession (DPoP) — RFC 9449
15. mTLS Certificate-bound Access Token Client API API Gateway Authorization Server public key private key { “cnf”: { “x5t#S256”: “bw…g2” } } mTLS mTLS
16. PAR
17. Pushed Authorization Requests • Standard defined in RFC 9126. • Provides means for confidential and integrity-protected authorization requests.
18. HTTP 400 Standard OAuth Authorization Requests GET /authorize?client_id=abc&scopes=read%20write HTTP 302 Location: /cb?code=123 Is that a legitimate client? Are the parameters OK? Can these end up in the browser logs? Client Authorization Server
19. Pushed Authorization Requests POST /authorize/par Authorization: Basic 0JjQlNCYOtCd0JDQpdCj0Jkh client_id=abc&scopes=read%20write request_id: 1234 GET /authorize?request_id=1234 Client Authorization Server
20. Pushed Authorization Requests • The client is authenticated before the authorization request. • Authorization request parameters can’t be tampered with. • Request parameters do not traverse through unsecure transport. • URL limitations are no longer a concern.
21. JARM
22. JWT Secured Authorization Response Mode • A specification from the OpenID Foundation. • Protects against attacks on the authorization code response.
23. Standard Response GET /authorize?client_id=abc&scopes=read%20write… HTTP 302 Location: https://example.com/cb?code=abcdef&state=1234 Was it issued by the correct Authorization Server? Does this code belong to this state? Client Authorization Server
24. JWT Secured Response GET /authorize?client_id=abc&scopes=read%20write… HTTP 302 Location: https://example.com/cb?response=eyJhbGciOiJSUzN… decode & verify { iss: https://idsvr.example.com , code: “abcdef”, state: “12345”, … } Client Authorization Server
25. JWT Secured Authorization Response Mode • The code response is integrity-protected. • Response parameters strongly coupled (mitigates replay attacks). • Protection from mix-up attacks (ability to verify iss claim).
26. Key Takeways • Regardless of your industry, have a look at the FAPI 2 Security Profile - it’s not a long document! • Protecting the access token is an important part of API security. • Use sender-constrained access tokens. • Protecting the access token means also protecting the flows — think of PAR, PKCE, JARM.
27. Thank You! https://curity.io