Token Authentication for Java Applications

Everyone building a web application that supports user login is concerned with security. How do you securely authenticate users and keep their identity secure? With the huge growth in Single Page Applications (SPAs), JavaScript and mobile applications, how do you keep users safe even though these are 'unsafe' client environments?

This presentation will demystify HTTP Authentication and explain how the Next Big Thing - Token Authentication - can be used to secure web applications on the JVM, REST APIs, and 'unsafe' clients while supporting security best practices and even improving your application's performance and scale.

Sign up for Stormpath: https://api.stormpath.com/register
More from Stormpath: https://stormpath.com/blog

Transcript

1. Securing Web Applications with Token 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 Concerns for Modern Web Apps • Cookies: need to know • Session ID Problems • Token Authentication to the rescue! • Java Example
4. Security Concerns for Modern 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-Site Scripting (XSS) attacks https://www.owasp.org/index.php/XSS Learn more at Stormpath.com
7. XSS Attack Demo https://www.google.com/about/appsecurity/le arning/xss/#BasicExample Learn more at Stormpath.com
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 J (more on this later) Learn more at Stormpath.com
12. Overview • Security Concerns for 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 Learn more 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 Control Rules 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 about cookies... 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 The Middle (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_ Request_Forgery_(CSRF)_Prevention_Cheat_S heet 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 Learn more at Stormpath.com
28. Double Submit Cookie Considerations • 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 Concerns for 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 Concerns for 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 • What is 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 you do it on the JVM? JJWT is awesome https://github.com/jwtk/jjwt Learn more at Stormpath.com
48. 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
49. How do you do 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 at Stormpath.com
51. Thanks! @lhazlewood @goStormpath • Token Authentication 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