Downloaded 108 times
![How do you do it on the JVM? import io.jsonwebtoken.Jwts; import io.jsonwebtoken.SignatureAlgorithm; byte[] key = getSignatureKey(); String jwt = Jwts.builder().setIssuer(“http://trustyapp.com/”) .setSubject(“users/1300819380”) .setExpiration(expirationDate) .put(“scope”, “self api/buy”) .signWith(SignatureAlgorithm.HS256,key) .compact(); Create a JWT: Learn more at Stormpath.com](https://image.slidesharecdn.com/tokenauthentication-150721011243-lva1-app6892/75/Token-Authentication-for-Java-Applications-48-2048.jpg)
Uploaded byStormpath
Token Authentication for Java Applications
The document discusses securing web applications through token authentication, emphasizing its advantages over traditional session ID-based methods. It outlines various security concerns, such as cross-site scripting (XSS) and cross-site request forgery (CSRF), and presents JSON Web Tokens (JWT) as a reliable authentication mechanism. The document also provides practical implementation details and resources for developers utilizing token authentication in their applications.
Token Authentication for Java Applications
- 1. Securing Web Applications withToken Authentication Les Hazlewood @lhazlewood PMC Chair, Apache Shiro Expert Group Member, JEE Application Security (JSR-375) Founder & CTO, Stormpath
- 2. About Stormpath • Authentication& User Management API • Hosted data store w/ advanced crypto • Centralize user login across your applications • Multi-tenant support for your SaaS • Active Directory, LDAP, social connections • API authentication & token authentication • Supported, Free tier for developers
- 3. Overview • Security Concernsfor Modern Web Apps • Cookies: need to know • Session ID Problems • Token Authentication to the rescue! • Java Example
- 4. Security Concerns forModern Web Apps • SPAs and Mobile apps are ‘Untrusted Clients’ • Prevent malicious code • Secure user credentials • Secure server endpoints (API) • Expose Access Control rules to the Client Learn more at Stormpath.com
- 5. Prevent Malicious Code •Cross-Site Scripting (XSS) attacks are a real, huge threat Learn more at Stormpath.com
- 6. Prevent Malicious Code Cross-SiteScripting (XSS) attacks https://www.owasp.org/index.php/XSS Learn more at Stormpath.com
- 7.
- 8. XSS Attack –What Can I Do? Read EVERYTHING on this page: https://www.owasp.org/index.php/XSS And then do these things: https://www.owasp.org/index.php/XSS_(Cross_Sit e_Scripting)_Prevention_Cheat_Sheet Learn more at Stormpath.com
- 9. XSS Attack –What Can I Do? Escape Content! Dynamic HTML: use well-known, trusted libraries. Do NOT roll your own. DOM attacks: escape user input Learn more at Stormpath.com
- 10. XSS Attack –What Can I Do? SPAs: frameworks like Angular probably do a lot of work for you (e.g. preventing DOM attacks by escaping user input). You should still read up on it. Learn more at Stormpath.com
- 11. Secure User Credentials •Traditionally, we have used Session IDs • This is OK, as long as you do cookies ‘right’ • Authentication Tokens are better (more on this later) Learn more at Stormpath.com
- 12. Overview • Security Concernsfor Modern Web Apps • Cookies: need to know • Session ID Problems • Token Authentication to the rescue! • Java Example Learn more at Stormpath.com
- 13. Session ID Cookies Learnmore at Stormpath.com
- 14. Secure Server (API)Endpoints • Traditionally use Session ID Cookies • Session ID Session User identity • Use framework like Apache Shiro or Spring Security to assert security rules Learn more at Stormpath.com
- 15. Expose Access ControlRules to the Client • Traditional solution: • Session ID Session User data in your DB • Provide a /me or /profile endpoint • Access Tokens are better! Learn more at Stormpath.com
- 16. Let’s talk aboutcookies... Learn more at Stormpath.com
- 17. Cookies are OK!If you do them correctly Cookies can be easily compromised: • Man-in-the-Middle (MITM) attacks • Cross-Site Request Forgery (CSRF) Learn more at Stormpath.com
- 18. Man In TheMiddle (MITM) attacks Someone ‘listening on the wire’ between the browser and server can see and copy the cookie. Solutions • Use HTTPS everywhere • TLS everywhere on internal networks Learn more at Stormpath.com
- 19. Cross-Site Request Forgery(CSRF) “... occurs when a malicious web site, email, blog, instant message or program causes a user’s web browser to perform an unwanted action on a trusted site for which the user is currently authenticated” https://www.owasp.org/index.php/CrossSite_Re quest_Forgery_(CSRF)_Prevention_Cheat_Sh eet Learn more at Stormpath.com
- 20. Cross-Site Request Forgery(CSRF) Attacker enables a user to request your server. Example: <a href=“https://yoursite.com/transferMo ney?to=BadGuy&amount=10000”>See Cute Cats!</a> What happens? Learn more at Stormpath.com
- 21. Cross-Site Request Forgery(CSRF) • The attacker cannot see your cookie values, BUT: • The browser says, “The request is going to your server, so I’ll happily send you your cookies.” • Your server transfers the money because it ‘sees’ a valid, non-expired session id cookie for an authenticated session. Learn more at Stormpath.com
- 22. Cross-Site Request Forgery(CSRF) Solutions • Synchronizer Token • Double-Submit Cookie • Origin header check Learn more at Stormpath.com
- 23. Synchronizer Token –Trusted Page Learn more at Stormpath.com
- 24. Synchronizer Token –Foreign Page Learn more at Stormpath.com
- 25. Synchronizer Token -Considerations • Requires cooperation from your rendering layer • Requires you to store tokens in a data store or cache • Difficult to do with static SPA content • Only protects against forged POST requests, not GETs! Pro tip: never allow GETs to modify server state! Learn more at Stormpath.com
- 26. Double Submit Cookie •Send two cookies: Session ID + Random Value • Send random value explicitly, browser Same- Origin-Policy • Best Way: send as a custom header Learn more at Stormpath.com
- 27. Double Submit Cookie Learnmore at Stormpath.com
- 28. Double Submit CookieConsiderations • Custom HTTP header, do what makes sense for your app • Still vulnerable to XSS - Random Value still accessible to the JS environment. • Protect against XSS! Learn more at Stormpath.com
- 29. Origin header check •Browsers send Origin header • Header value is the domain of the page initiating the request • Cannot be hacked via browser JS (could still be modified by a malicious HTTP proxy server) Learn more at Stormpath.com
- 30. Overview • Security Concernsfor Modern Web Apps • Cookies: need to know • Session ID Problems • Token Authentication to the rescue! • Java Example Learn more at Stormpath.com
- 31. Session ID Problems •They’re opaque and have no meaning themselves (they’re just ‘pointers’). • Service-oriented architectures might need a centralized ID de-referencing service Learn more at Stormpath.com
- 32. Session ID Problems •Opaque IDs mean clients can’t inspect them and find out what it is allowed to do or not - it needs to make more requests for this information. Learn more at Stormpath.com
- 33. Session ID Problems •Sessions = Server State! • You need to store that state somewhere • Session ID look up server state on *every request*. • Really not good for distributed/clustered apps • Really not good for scale Learn more at Stormpath.com
- 34. Overview • Security Concernsfor Modern Web Apps • Cookies: need to know • Session ID Problems • Token Authentication to the rescue! • Java Example Learn more at Stormpath.com
- 35. Token Authentication • Whatis Authentication? • What is a Token? Learn more at Stormpath.com
- 36. JSON Web Tokens(JWT) • A URL-safe, compact, self-contained string with meaningful information that is usually digitally signed or encrypted. • The string is ‘opaque’ and can be used as a ‘token’. • Many OAuth2 implementations use JWTs as OAuth2 Access Tokens. Learn more at Stormpath.com
- 37. JSON Web Tokens(JWT) • You can store them in cookies! But all those cookie rules still apply. • You can entirely replace your session ID with a JWT. Learn more at Stormpath.com
- 38. JSON Web Tokens(JWT) In the wild they look like just another ugly string: eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9.eyJ pc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQo gImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnV lfQ.dBjftJeZ4CVPmB92K27uhbUJU1p1r_wW1gFWFOEj Xk Learn more at Stormpath.com
- 39. JSON Web Tokens(JWT) But they do have a three part structure. Each part is a Base64-encoded string: eyJ0eXAiOiJKV1QiLA0KICJhb GciOiJIUzI1NiJ9 . eyJpc3MiOiJqb2UiLA0KICJle HAiOjEzMDA4MTkzODAsDQogIm h0dHA6Ly9leGFtcGxlLmNvbS9 pc19yb290Ijp0cnVlfQ . dBjftJeZ4CVPmB92K27uhbUJU 1p1r_wW1gFWFOEjXk Header Body (‘Claims’) Cryptographic Signature Learn more at Stormpath.com
- 40. JSON Web Tokens(JWT) Base64-decode the parts to find the juicy bits: { "typ":"JWT", "alg":"HS256" } { "iss”:”http://trustyapp.com/”, "exp": 1300819380, “sub”: ”users/8983462”, “scope”: “self api/buy” } tß´—™à%O˜v+nî…SZu¯µ€U…8H× Header Body (‘Claims’) Cryptographic Signature Learn more at Stormpath.com
- 41. JSON Web Tokens(JWT) The claims body is the best part! It can tell: { "iss”:”http://trustyapp.com/”, "exp": 1300819380, “sub”: ”users/8983462”, “scope”: “self api/buy” } Who issued the token Learn more at Stormpath.com
- 42. JSON Web Tokens(JWT) The claims body is the best part! It can tell: { "iss”:”http://trustyapp.com/”, "exp": 1300819380, “sub”: ”users/8983462”, “scope”: “self api/buy” } Who issued the token When it expires Learn more at Stormpath.com
- 43. JSON Web Tokens(JWT) The claims body is the best part! It can tell: { "iss”:”http://trustyapp.com/”, "exp": 1300819380, “sub”: ”users/8983462”, “scope”: “self api/buy” } Who issued the token When it expires Who it represents Learn more at Stormpath.com
- 44. JSON Web Tokens(JWT) The claims body is the best part! It can tell: { "iss”:”http://trustyapp.com/”, "exp": 1300819380, “sub”: ”users/8983462”, “scope”: “self api/buy” } Who issued the token When it expires Who it represents What they can do Learn more at Stormpath.com
- 45. JSON Web Tokens(JWT) Great! Why is this useful? • Implicitly trusted because it is cryptographically signed (verified not tampered). • It is structured, enabling inter-op between services • It can inform your client about basic access control rules (permissions)* • And the big one: statelessness! *servers must always enforce access control policies Learn more at Stormpath.com
- 46. JSON Web Tokens(JWT) So, what’s the catch? • Implicit trust is a tradeoff – how long should the token be good for? how will you revoke it? (Another talk: refresh tokens) • You still have to secure your cookies! • You have to be mindful of what you store in the JWT if they are not encrypted. No sensitive info! Learn more at Stormpath.com
- 47. How do youdo it on the JVM? JJWT is awesome https://github.com/jwtk/jjwt Learn more at Stormpath.com
- 48. How do youdo it on the JVM? import io.jsonwebtoken.Jwts; import io.jsonwebtoken.SignatureAlgorithm; byte[] key = getSignatureKey(); String jwt = Jwts.builder().setIssuer(“http://trustyapp.com/”) .setSubject(“users/1300819380”) .setExpiration(expirationDate) .put(“scope”, “self api/buy”) .signWith(SignatureAlgorithm.HS256,key) .compact(); Create a JWT: Learn more at Stormpath.com
- 49. How do youdo it on the JVM? Verify a JWT: try { Jws<Claims> jwt = Jwts.parser().setSigningKey(key).parseClaimsJws(jwt); //OK, we can trust this JWT } catch (SignatureException e) { //don't trust the JWT! } Learn more at Stormpath.com
- 50. Demo! Learn more atStormpath.com
- 51. Thanks! @lhazlewood @goStormpath • TokenAuthentication for Java, Spring and Spring Boot • Free Supported Developer Tier • Elegant API • OSS Java SDKs + Tutorials Get a Free-Forever Account: Stormpath.com Learn more at Stormpath.com