Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.

Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.

Stateless authentication with OAuth 2 and JWT - JavaZone 2015

This talk is about how to secure your front-end + backend applications using a RESTful approach. As opposed to traditional and monolithic server-side applications (where the HTTP session is used), when your front-end application is running on a browser and not securely from the server, there are few things you need to consider. In this session Alvaro will explore standards like OAuth and JWT to achieve a stateless, token-based authentication and authorisation. He will explore the existing impl More specifically, the demonstration will be made using Spring Security REST, a popular Grails plugin written by Álvaro.
Authentication is normally a stateful service. Most of the implementations rely on the HTTP session, thus introducing state as the session is an in-memory data structure in the application server.

In the microservices era, most of the companies are developing such called RESTful services, where one of the principles is to create stateless systems. In such scenario, authentication should be stateless too.

There is a standard specification to secure web application and API's, that is being adopted massively by the industry: OAuth 2. The specification doesn't explicitly cover how to make a stateless implementation. And most of the existing ones depend on some sort of external storage (such as a DB) to store the tokens generated for a later validation.

Fortunately, there is another specification by the IETF called JSON Web Token, that can be combined with OAuth 2 to achieve a stateless authentication system.

In the session, Alvaro will explain the core concepts of OAuth 2, as well as JWT and how can them be used together to achieve the last 2 letters of REST: State Transfer.

8.
@alvaro_sanchez
Authentication in monolithic apps
● Historically, authentication has always been a
stateful service.
● When moving to Single-Page Applications,
and/or having mobile clients, it becomes an
issue.
● If you are build a REST and stateless API, your
authentication should be that way too.

13.
@alvaro_sanchez
Authentication and microservices
● Authentication: to verify the identity of the
user given the credentials received.
● Authorization: to determine if the user should
be granted access to a particular resource.
● In a microservices context:
○ Authentication can be a microservice itself.
○ Authorization is a common functionality in all of them.

16.
@alvaro_sanchez
Introducing OAuth 2.0
An open protocol to allow secure authorization
in a simple and standard method from web,
mobile and desktop applications.

17.
@alvaro_sanchez
OAuth 2.0: roles
Resource Owner: the person or the application
that holds the data to be shared.
Resource Server: the application that holds the
protected resources.
Authorization Server: the application that
verifies the identity of the users.
Client: the application that makes requests to
the RS on behalf of the RO.

18.
@alvaro_sanchez
OAuth 2.0: roles
Resource Owner: the person or the application
that holds the data to be shared.
Resource Server: the application that holds the
protected resources.
Authorization Server: the application that
verifies the identity of the users.
Client: the application that makes requests to
the RS on behalf of the RO.

19.
@alvaro_sanchez
OAuth 2.0: roles
Resource Owner: the person or the application
that holds the data to be shared.
Resource Server: the application that holds the
protected resources.
Authorization Server: the application that
verifies the identity of the users.
Client: the application that makes requests to
the RS on behalf of the RO.

20.
@alvaro_sanchez
OAuth 2.0: roles
Resource Owner: the person or the application
that holds the data to be shared.
Resource Server: the application that holds the
protected resources.
Authorization Server: the application that
verifies the identity of the users.
Client: the application that makes requests to
the RS on behalf of the RO.

21.
@alvaro_sanchez
OAuth 2.0: protocol flow
I want to see a list of games

36.
@alvaro_sanchez
Authorization code grant
● For server-based applications, where the
client ID and secret are securely stored.
● It’s a redirect flow, so it’s for web server apps.
● The client (web server app) redirects the user
to the authorization server to get a code.
● Then, using the code and its client credentials
asks for an access token.

56.
@alvaro_sanchez
Accessing the protected resource
Once the client has an access token, it can
request a protected resource:
GET /games HTTP/1.1
Host: api.example.org
Authorization: Bearer RsT5OjbzRn430zqMLgV3Ia

57.
@alvaro_sanchez
Token expiration and refresh
● If the Authorization Server issues expiring
tokens, they can be paired with refresh
tokens.
● When the access token has expired, the
refresh token can be used to get a new access
token.

58.
@alvaro_sanchez
Tips for a front-end application
● Use the implicit grant.
○ Already supported for 3rd party providers like Google,
Facebook.
○ If you hold your own users, have your backend to
implement the OAuth 2.0 Authorization Server role.
● Use HTML5’s localStorage for access and
refresh tokens.

67.
@alvaro_sanchez
Introducing JWT
JSON Web Token is a compact URL-safe means of
representing claims to be transferred between
two parties. The claims are encoded as a JSON
object that is digitally signed by hashing it using
a shared secret between the parties.

68.
@alvaro_sanchez
Introducing JWT... in Plain English
A secure way to encapsulate arbitrary data that
can be sent over unsecure URL’s.

69.
@alvaro_sanchez
When can JWT be useful?
● When generating “one click” action emails.
○ Eg: “delete this comment”, “add this to favorites”.
● To achieve Single Sign-On.
○ Sharing the JWT between different applications.
● Whenever you need to securely send a payload.
○ Eg: to “obscure” URL parameters or POST bodies.

77.
@alvaro_sanchez
Achieving statelessness
● Instead of storing the access token / principal
relationship in a stateful way, do it on a JWT.
● Access tokens with the JWT-encoded
principal can be securely stored on the client’s
browser.
● That way you are achieving one of the basic
principles of REST: State Transfer.

78.
@alvaro_sanchez
Tips for using JWT
● JWT claims are normally just signed (JWS -
JSON Web Signature).
○ It prevents the content to be tampered.
● Use encryption to make it bomb proof.
○ Use any algorithm supported by JWE - JSON Web
Encryption.
○ But be aware of performance!