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. Pushed Authorization
Requests (PAR)

14. Pushed Authorization Requests
• Standard defined in RFC 9126.
• Provides means for confidential and integrity-protected
authorization requests.

15. 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

16. 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

17. 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

18. JWT Secured Authorization
Response Mode (JARM)

19. JWT Secured Authorization Response Mode
• A specification from the OpenID Foundation
• Protects against attacks on the authorization code response

20. 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

21. 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

22. 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).

23. The Phantom Token
Pattern

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

25. 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

26. Client
Token Introspection
opaque
Authorization
Server
API
Gateway
API

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

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

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

30. The Phantom Token Flow
Benefits:
• Better security and privacy
• Performance optimization, especially when properly using
cache

31. • Safeguard against usage of stolen/lost tokens
• Protect request and response using PAR & JARM
• Prevent confidential data from leaking or being misused
Key Takeways

32. Thank You!
Booth #2
curity.io
developer.curity.io
@curityio
info@curity.io