Are you worried that your REST API may be the next victim of an attack by ruthless hackers? Don't fret. Utilizing the same standards implemented by OAuth 2.0 and OpenID Connect, you can secure your REST API. Open and proven standards are the best ways to secure your REST APIs for now and well into the future. JSON Object Signing and Encryption (JOSE) is the core of a truly secure standards based REST API. In this talk, you will learn how to use the components of JOSE to secure your REST API for now and the future.
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
7. @adam_englander
2015 Changed All Of That
IETF RFC 7523: JSON Web Token (JWT) Profile
for OAuth 2.0 Client Authentication and Authorization Grants
9. @adam_englander
Why Was It A Big Deal?
• 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
13. @adam_englander
Data
• RESTish Web API
• Query parameters for GET including encrypted
data and signature
• Mostly form encoded requests for POST/PUT/
DELETE
• JSON responses
14. @adam_englander
Credentials
• Silo credentials for entity types
• Random integers for identifiers
• Passwords sent in encrypted package
• Password rotation with old password expiring
one hour after new password generated.
16. @adam_englander
Security
• Replay prevention for requester ID and
timestamp
• Signature verification for password and
timestamp
• Encrypted password and timestamp
• Rate limited by requester ID and subject
17. @adam_englander
The Good — Security
• The API was never compromised even though
there has been a bug bounty for four years
• It passed multiple static and dynamic analyses
from top security analysis firms
• No-one has ever been able to fabricate an
authorization ever
18. @adam_englander
The Bad — Usability
• Has its own way of doing things
• API is not uniform in data and encryption
• Security trumped RESTful
• Too many credentials to manage
• No proper credential rotation
21. @adam_englander
What We Gained
• Began using an open standard for data security
• We added a private claim for as SHA-256 hash
of the request body
• A more secure API request format
22. @adam_englander
What Was Missing
• Still using custom and inconsistent encryption
• Did not increase the RESTful quality
• Did not sign the entire request
• Did not reduce the quantity of credentials
• Did not improve the response
24. @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
25. @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
26. @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
27. @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
28. @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
29. @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
32. @adam_englander
What is JOSE?
• JavaScript Object Signing and Encryption encompasses:
• JSON Web Token (JWT)
• JSON Web Signature (JWS)
• JSON Web Encryption (JWE)
• JSON Web Algorithm (JWA)
• JSON Web Key (KWK)
33. @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
34. @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
35. @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
36. @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
37. @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.
38. @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.
42. @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
44. @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
59. @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
61. @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