The learning curve for security is severe and unforgiving. Specifications promise infinite flexibility, habitually give old concepts new names, are riddled with extensions, and almost seem designed to deliberately confuse. For a back-end REST developer, choking all this down for the first time is mission impossible. With an aggressive distaste for fancy terminology, this session delves into OAuth 2.0 as it pertains to REST and shows how it falls into two camps: stateful and stateless. The presentation also details a competing Amazon-style approach called HTTP Signatures and digs into the architectural differences of all three, with a heavy focus on the wire, showing actual HTTP messages and enough detail to have you thinking, “I could write this myself.”
46. JavaOne
#RESTSecurity @dblevins @tomitribe
Access Token Now
• header (JSON > Base64 URL Encoded)
• describes how the token signature can be checked
• payload (JSON > Base64 URL Encoded)
• Basically a map of whatever you want to put in it
• Some standard keys such as expiration
• signature (Binary > Base64 URL Encoded
• The actual digital signature
• made exclusively by the /oauth2/token endpoint
• If RSA, can be checked by anyone
79. JavaOne
#RESTSecurity @dblevins @tomitribe
Observations
• HTTP Signatures the only HTTP friendly approach
• Signatures does not solve the “Identity Load” problem
• OAuth 2 with JWT significantly improves IDP load
• Plain OAuth 2
• HTTP Session-like implications
• OAuth 2 with JWT
• Signed cookie
• Signing key to the future