Enhancing API Security and Privacy Through Hardening the Access Token | apidays New York 2024

Slides from Jonas Iggbom's workshop on enhancing API security and privacy through hardening the access token.

apidays New York, April 30 - May 2, 2024

1. Enhancing API Security and Privacy Through Hardening the Access Token

2. Jonas Iggbom Director of Sales Engineering

3. Who needs secure APIs? mTLS Sender-constrained access tokens PAR JARM The Phantom Token Pattern Agenda

4. Who Needs Secure APIs? Finance Medical Sensitive data

5. mTLS

6. TLS Client Server

7. mTLS = mutual TLS Client

8. Sender-constrained tokens

9. Bearer tokens Sender-constrained tokens / Proof-of-Possession tokens Sender-constrained Tokens

10. Client 2 Client 1 Bearer Tokens API API Gateway

11. Client 2 Client 1 Sender-constrained Tokens API Gateway API

12. Client Authorization Server private key mTLS mTLS Sender-constrained Tokens API Gateway API

13. Proof-of-Possession for JWTs Standard defined in RFC 7800. Adds a “cnf” (confirmation) claim to the token, which enables the recipient to verify the caller.

14. PoP JWTs with “cnf” claim Client API API Gateway Authorization Server public key private key + proof of { “cnf”: { “kid”: “1234” } } + proof of

15. OAuth 2.0 Demonstrating Proof of Possession (DPoP) Standard defined in RFC 9449. Sender constrained tokens with JWT-bases proofs. Useful when it is not possible to use mTLS.

16. Pushed Authorization Requests (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 Ability to ease on redirect URI restrictions

21. JWT Secured Authorization Response Mode (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. The Phantom Token Pattern

27. By-value vs. By-reference Client JWT Authorization Server opaque

28. By-value vs. By-reference Opaque tokens should always be your preferred choice: Data in a JWT is meant for the API, not the client Data in a JWT is public – danger of releasing PII or information about your API Risk of damaging integrations with incompatible changes

29. Client Token Introspection opaque Authorization Server API Gateway API

30. Token Introspection Client Service 1 Service 2 opaque Authorization Server API Gateway API

31. The Phantom Token Flow Client API Service 1 Service 2 Authorization Server opaque JWT API Gateway

32. The Phantom Token Flow Client API Authorization Server = Cache API Gateway