Many developers struggle with how to properly secure REST APIs. If you are like me, you followed a process from a trusted provider like Amazon, Google, etc. What if I told you there was a better way? It’s JOSE, a collection of open standards from the IETF that has strong library support. It’s also the basis of OAuth 2.0 and OpenID Connect. Let me show you how to make a highly secure API for today and well into the future built on the framework of JOSE.
3. @adam_englander
This is what I looked
like when I started
working on APIs
It was so long ago that SOAP was the
new hotness.
4. @adam_englander
Over The Years
• 2001 — Global Authentication Service API
• 2008 — Loan Application Ping Tree
• 2010 — Loan Management System API
• 2012 — Advertising Network API
• 2013 — Real Time Loan Risk Assessment API
• 2015 — Decentralized Multi-Factor Authorization API
6. @adam_englander
Auth and Crypto Was Messy
• Auth as part of the message added complexity
• Auth outside of the message lost context
• Every implementation was specialized
• Crypto was non-standard and static
• Non-experts had to write a lot of code
8. @adam_englander
We Identified Gaps
• Authentication was part of the request
• Signature was incomplete on request and absent on
response
• Key rotation was difficult if not impossible
• Algorithms were pinned to lowest common denominator
• To much crypto knowledge required without SDK
10. @adam_englander
Why JOSE?
• Authentication, authorization, encryption, and
data integrity validation are not tied to the
protocol
• OAuth, OpenID, and FIDO adopting the
standard gave it credibility, stability, and
longevity as an IETF working group
11. @adam_englander
What Changed?
• JWT with custom claims used to validate entire
request and critical portions of the response
• JWE to encrypt request and response
• JWA for future proofing cryptography
• JWK for credential rotation
• Removed password entirely
13. @adam_englander
A Whole Lot of JOSE
• JSON Web Token (JWT)
• JSON Web Signature (JWS)
• JSON Web Encryption (JWE)
• JSON Web Algorithm (JWA)
• JSON Web Key (KWK)
14. @adam_englander
JSON Web Signature (JWS)
JWS is comprised of three segments:
1. Header provides key information, signature
algorithm, and optionally content metadata
2. Payload is the data to be signed
3. Signature of the header and payload
15. @adam_englander
JSON Web Token (JWT)
• JWT is actually a JSON Web Signature (JWS)
package with standardized payload in the form
of Claims.
• Provides for credentials, nonce, timestamp, and
duration
• Private claims can be added for extensibility
16. @adam_englander
JSON Web Encryption (JWE)
JSON Web Encryption contains five segments:
1. Header provides key management mode, key
information, key encryption algorithm, content
encryption algorithm, and optionally content metadata
2. Content Encryption Key (CEK) may contain generated
symmetric keys used for encryption and HMAC that
are encrypted using asymmetric key encryption
17. @adam_englander
JSON Web Encryption (JWE)
3. Initialization Vector for encrypting the payload
4. Encrypted payload
5. Authentication tag is an HMAC of the header,
IV, and encrypted payload
18. @adam_englander
JSON Web Algorithm
• Standardized format for expressing encryption
and signature algorithms.
• Used by JWE/JWS with “enc” and “alg” keys in
the header.
19. @adam_englander
JSON Web Key
• Standardized format for expressing keys used
for JWE and JWS.
• Provides for key identification.
• Used by JWE/JWS with number of keys in the
header which are determined by the key type.
20. @adam_englander
The Good — Decoupling
• Authentication, authorization, validation, encryption
and decryption was moved to middleware
• Controllers handled only HTTP/JSON which greatly
reduced code complexity
• Better unit testing across the board
• Reduced development times for new functionality
21. @adam_englander
The Good — OSS Libraries
• We can test our API without requiring our own
client SDK
• Client SDKs are less complex
• OSS contributions are actually possible
• Documentation complexity was reduced
22. @adam_englander
The Good — Uniformity Across APIs
• All APIs will be migrated to JOSE
• Different key implementations are possible
• Shared knowledge across vastly different teams
• Federated authentication is attainable
23. @adam_englander
The Good — Hierarchical Auth
• JWT inclusion of issuer, subject, and audience
allows for a parent to provide credentials for
action on a sibling with proper context.
• JWK allows for easy identification of credentials
used
24. @adam_englander
The Bad
• Some languages have minimal support for
algorithms and strengths
• Some languages have no support for JWE. We
had to write our own minimal Objective-C
implementation
• Some good documentation but a good working
knowledge requires reading RFCs
28. @adam_englander
Key Rotation
• Key ID id provided in request and response
• Current and specific public keys are available via
endpoint
• https://api.launchkey.com/public/v3/public-key/
09:f7:e0:2f:12:90:be:21:1d:a7:07:a2:66:f1:53:b3
• https://api.launchkey.com/public/v3/public-key
30. @adam_englander
Request Authorization
• Single use JSON Web Token (JWT) in Authorization
header as Authorization scheme IOV-JWT
• RSA key signature
• Hierarchical ACL: Org -> Dir -> Service
• Token ID as nonce
• Private claims: request
46. @adam_englander
JWT Validation Example
$checkerManager = new CheckerManager();
$checkerManager->addClaimChecker(new IssuedAtChecker());
$jwtLoader = new JWTLoader(
$checkerManager,
new Verifier(['RS512'])
);
$keySet = new JWKSet();
$keySet->addKey(JWKFactory::createFromKeyFile(
'./public.key'
));
$jws = $jwtLoader->load($jwt, $keySet);
$jwtLoader->verify($jws, $keySet);
47. @adam_englander
Encrypted Data with JWE
• JWK provides for key rotation
• Combination of RSA and AES encryption is always
used
• Algorithms and modes are always the same
• Key size is variable in allowed range
• Response uses same AES key size as request
51. @adam_englander
Conclusion
• JOSE has made our secure API more secure
• JOSE has made our API easier to use
• JOSE has made our code less complex
• JOSE has homogenized auth and crypto across
multiple platforms regardless of language