token authentication for java applications

Securing Web Applications with Token AuthenticationLes Hazlewood @lhazlewood

PMC Chair, Apache Shiro

Expert Group Member, JEE Application Security (JSR-375)

Founder & CTO, Stormpath

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

Overview

• Security Concerns for Modern Web Apps

• Cookies: need to know

• Session ID Problems

• Token Authentication to the rescue!

• Java Example

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

https://stormpath.com/?utm_source=slideshare&utm_medium=slide%20link&utm_campaign=java%20token%20authentication%20slides

Prevent Malicious Code

• Cross-Site Scripting (XSS) attacks are a real, huge threat

Prevent Malicious Code

Cross-Site Scripting (XSS) attacks

https://www.owasp.org/index.php/XSS

XSS Attack

Demo

https://www.google.com/about/appsecurity/learning/xss/#BasicExample

https://www.google.com/about/appsecurity/learning/xss/%23BasicExample

XSS Attack – What Can I Do?

Read EVERYTHING on this page:

And then do these things:

https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

Escape Content!

Dynamic HTML: use well-known, trusted libraries. Do NOT roll your own.

DOM attacks: escape user input

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.

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)

Overview

• Java Example

Session ID Cookies

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

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!

Let’s talk about cookies...

Cookies are OK! If you do them correctly

Cookies can be easily compromised:

• Man-in-the-Middle (MITM) attacks

• Cross-Site Request Forgery (CSRF)

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

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_Sheet

Attacker enables a user to request your server. Example:

What happens?Learn more at Stormpath.com

https://yoursite.com/transferMoney?to=BadGuy&amount=10000

• 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.

Solutions

• Synchronizer Token

• Double-Submit Cookie

• Origin header check

Synchronizer Token – Trusted Page

Synchronizer Token – Foreign Page

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!

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

Double Submit Cookie

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!

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)

Overview

• Java Example

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

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.

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

Overview

• Java Example

Token Authentication

• What is Authentication?

• What is a Token?

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.

• You can store them in cookies! But all those cookie rules still apply.

• You can entirely replace your session ID with a JWT.

In the wild they look like just another ugly string:

eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ.dBjftJeZ4CVPmB92K27uhbUJU1p1r_wW1gFWFOEjXk

But they do have a three part structure. Each part is a Base64-encoded string:

eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ.dBjftJeZ4CVPmB92K27uhbUJU1p1r_wW1gFWFOEjXk

Header

Body (‘Claims’)

Cryptographic Signature

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

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

"exp": 1300819380,

“sub”: ”users/8983462”,

}

When it expires

"exp": 1300819380,

“sub”: ”users/8983462”,

}

When it expires

Who it represents

"exp": 1300819380,

“sub”: ”users/8983462”,

}

When it expires

Who it represents

What they can do

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

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!

How do you do it on the JVM?

JJWT is awesome

https://github.com/jwtk/jjwt

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:

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!}

Demo!

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

token authentication for java applications

session id session user

modern web apps cookies

session ids

user input

malicious web site

user login

security rules

dom attacks

Software

fortitoken two factor authentication · 2018-10-23 ·...

stateless token-based authentication for pure front-end...

modified usb security token for user authentication ·...

symfony guard authentication: fun with api token, social...

token authentication in asp.net core--stormpath webinar

safenet authentication service token validator …...

article title: “ token-based graphical password...

securing single page applications with token based...

the wonderful story of web authentication and single sign...

outline user authentication –password authentication, salt...

the german eid as an authentication token on android devices

rfp token based otp authentication solution - idbi bank

low-cost protection against cold boot attacks for an...

manual do usuário token safenet authentication cliente 8.3...

authentication using one-time password token and smart...

beyond x.509: token-based authentication and authorization...

waffle: windows authentication in java

lemonldap::ng 2.0 - fosdem 2019 · sso workfow...

token token user groups roles claims authentication provider...

a secure and performant token-based authentication for...