Stateless authentication for microservices

Stateless authentication for
microservices
Álvaro Sánchez-Mariscal
Web Architect -
@alvaro_sanchez

@alvaro_sanchez
About me
● Passionate Software Developer.
● Worked at IBM BCS, BEA Systems and Sun
Microsystems.
● Founded Salenda and Escuela de Groovy.
● Working now at as a Web Architect.
● Living between Madrid and Gibraltar.

@alvaro_sanchez
About
● HTML5 games platform.
● We provide game developers a Javascript SDK.
● Server side logic and maths are handled by our
industry certified game engines.
● Seamless integration with several casinos.
● Check out play.odobo.com and play for free!

@alvaro_sanchez
Agenda
1. Authentication in monolithic applications vs
microservices.
2. Introduction to OAuth 2.0.
3. Achieving statelessness with JWT.
4. The Grails plugin.
5. Q&A.

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.
@alvaro_sanchez

Microservices by http://martinfowler.com/articles/microservices.
@alvaro_sanchez
html

Monolithic vs Microservices
Monolithic
Microservices
@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.
@alvaro_sanchez

Authentication and microservices
Authentication
Service
@alvaro_sanchez
Javascript front-end
UI
Mobile app
Shopping cart
Service
Catalog
Service
Orders Service
Shipping
Service
User
repository
Catalog DB
Invoicing
DB
Shipping
partners
Web
Backend
Mobile
Backend

Introducing OAuth 2.0
An open protocol to allow secure authorization
in a simple and standard method from web,
mobile and desktop applications.
@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.
@alvaro_sanchez

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

Hey, backend, could you please give me a list of
games?
@alvaro_sanchez

Sorry mate, this is a protected resource. You will
need to present me an access token
@alvaro_sanchez

Hi Google, can I get an access token please?
Backend is asking
@alvaro_sanchez

Sure thing sir. I just need to ask a few details to
@alvaro_sanchez
the user first

Hi, could you please provide me your
credentials? I need to verify your identity
@alvaro_sanchez

That’s no problem at all. I am bob@gmail.com and
my password is secret.
@alvaro_sanchez

The user is who claims to be. Here is your access
token: qfE2KhvKggluHqe7IpTBqZ4qziTQQbKa
@alvaro_sanchez

Hi Backend, this is my token:
qfE2KhvKggluHqe7IpTBqZ4qziTQQbKa
@alvaro_sanchez

Hi, I’ve been given qfE2KhvKggluHqe7IpTBqZ4qziTQQbKa.
Could you please tell me who it belongs to?
@alvaro_sanchez

Of course. That token is still valid and it belongs to
@alvaro_sanchez
bob@gmail.com.

Everything is allright. This is the list of games.
@alvaro_sanchez
Enjoy!

Here you are the list of games.Thank you for your
business and have a good day!
@alvaro_sanchez

OAuth 2.0 is a delegation protocol, as
this guy has no idea about the
credentials of this guy
@alvaro_sanchez

OAuth 2.0: grant types
● Authorization code: for web server
applications.
● Implicit: for JS front-ends and mobile apps.
● Resource Owner Password Credentials: for
trusted clients.
● Client credentials: for service authentication.
@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.
@alvaro_sanchez

http://myServerApp.com
@alvaro_sanchez

https://facebook.com/dialog/oauth
?response_type=code
&client_id=YOUR_CLIENT_ID
&redirect_uri=
http://myServerApp.com/oauth
&scope=email,public_profile
@alvaro_sanchez

hhttttpp::////fmacyeSbeorvoekr.Acopmp.com
@alvaro_sanchez

hhttttpp:s/://m/faycSeebrvoeorkA.cpopm.com
@alvaro_sanchez

https://myServerApp.com/oauth?code=CODE
Finishing authentication...
@alvaro_sanchez

Server-side POST request to: https://graph.
facebook.com/oauth/access_token
With this body:
grant_type=authorization_code
&code=CODE_FROM_QUERY_STRING
&redirect_uri=http://myServerApp.com
&client_secret=YOUR_CLIENT_SECRET
@alvaro_sanchez

Example response:
{
"access_token": "RsT5OjbzRn430zqMLgV3Ia",
"token_type": "Bearer",
"expires_in": 3600,
"refresh_token": "e1qoXg7Ik2RRua48lXIV"
@alvaro_sanchez
}

@alvaro_sanchez
Implicit grant
● For web applications running on the browser
(eg: AngularJS, etc) or mobile apps.
● Client credentials confidentiality cannot be
guaranteed.
● Similar to the code grant, but in this case, the
client gets an access token directly.

@alvaro_sanchez
Implicit grant
http://myFrontendApp.com/#/home

@alvaro_sanchez
Implicit grant
https://facebook.com/dialog/oauth
?response_type=token
&redirect_uri=
http://myFrontendApp.com/#/cb
&scope=email,public_profile

@alvaro_sanchez
Implicit grant
hhttttpp:s/://m/faycSeebrvoeorkA.cpopm.com

@alvaro_sanchez
Implicit grant
https://myFrontendApp.com/#/cb?token=TOKEN
Finishing authentication...

Password credentials grant
● In this case, client collects username and
password to get an access token directly.
● Viable solution only for trusted clients:
○ The official website consumer of your API.
○ The official mobile app consuming your API.
○ Etc.
@alvaro_sanchez

@alvaro_sanchez

POST request to: https://api.example.
org/oauth/access_token
With this body:
grant_type=password
&username=USERNAME&password=PASSWORD
@alvaro_sanchez

Example response:
{
"expires_in": 3600,
@alvaro_sanchez
}

Client credentials grant
● Service-to-service authentication, without a
particular user being involved.
○ Eg: the Orders microservice making a request to the
Invoicing microservice.
● The application authenticates itself using its
client ID and client secret.
@alvaro_sanchez

POST request to: https://api.example.
org/oauth/access_token
With this body:
grant_type=client_credentials
@alvaro_sanchez

Example response:
{
"expires_in": 3600,
@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
@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.
@alvaro_sanchez

Tips for a front-end application
● Use the implicit grant.
○ Already supported for 3rd party providers like Google,
@alvaro_sanchez
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.

Stateful vs. Stateless
● Authorization Servers are often stateful
services.
○ They store issued access tokens in databases for future
@alvaro_sanchez
checking.
● How can we achieve statelessness?
○ Issuing JWT tokens as access tokens.

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.
@alvaro_sanchez

Introducing JWT... in Plain English
A secure way to encapsulate arbitrary data that
can be sent over unsecure URL’s.
@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.
@alvaro_sanchez

How does a JWT look like?
Header Claims
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJleHAiOjE0MTY0NzE5MzQsInVzZXJfbmFtZSI6InV
zZXIiLCJzY29wZSI6WyJyZWFkIiwid3JpdGUiXSwiYX
V0aG9yaXRpZXMiOlsiUk9MRV9BRE1JTiIsIlJPTEVfV
VNFUiJdLCJqdGkiOiI5YmM5MmE0NC0wYjFhLTRjNWUt
YmU3MC1kYTUyMDc1YjlhODQiLCJjbGllbnRfaWQiOiJ
teS1jbGllbnQtd2l0aC1zZWNyZXQifQ.
AZCTD_fiCcnrQR5X7rJBQ5rO-2Qedc5_3qJJf-ZCvVY
@alvaro_sanchez
Signature

@alvaro_sanchez
JWT Header
{
"alg": "HS256",
"typ": "JWT"
}

@alvaro_sanchez
JWT Claims
{
"exp": 1416471934,
"user_name": "user",
"scope": [
"read",
"write"
],
"authorities": [
"ROLE_ADMIN",
"ROLE_USER"
],
"jti": "9bc92a44-0b1a-4c5e-be70-da52075b9a84",
"client_id": "my-client-with-secret"
}

@alvaro_sanchez
Signature
HMACSHA256(
base64(header) + "." + base64(payload),
"secret"
)

Sample access token response
@alvaro_sanchez
{
"access_token": "eyJhbGciOiJIUzI1NiJ9.
eyJleHAiOjE0MTY0NzEwNTUsInVzZXJfbmFtZSI6InVzZXIiLCJzY29wZS
I6WyJyZWFkIiwid3JpdGUiXSwiYXV0aG9yaXRpZXMiOlsiUk9MRV9BRE1J
TiIsIlJPTEVfVVNFUiJdLCJqdGkiOiIzZGJjODE4Yi0wMjAyLTRiYzItYT
djZi1mMmZlNjY4MjAyMmEiLCJjbGllbnRfaWQiOiJteS1jbGllbnQtd2l0
aC1zZWNyZXQifQ.
Wao_6hLnOeMHS4HEel1UGWt1g86ad9N0qCexr1IL7IM",
"token_type": "bearer",
"expires_in": 43199,
"scope": "read write",
"jti": "3dbc818b-0202-4bc2-a7cf-f2fe6682022a"
}

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.
@alvaro_sanchez

Tips for using JWT
● JWT claims are just signed by default (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
@alvaro_sanchez
Encryption.

It all started here, one year ago
@alvaro_sanchez

@alvaro_sanchez
One year later
● Spring Security REST plugin.
○ 16 contributors.
○ 34 pull requests.
○ 59 stars on GitHub.
○ 16 releases.
○ http://bit.ly/spring-security-rest

Happy users == happy author
@alvaro_sanchez

Current status
● Latest release: 1.4.0.
● Compatibility layer over Spring Security Core.
○ Login and logout REST endpoints.
○ Token validation filter.
○ Memcached, GORM and Grails Cache token storages.
○ Partial implicit grant support through 3rd party
@alvaro_sanchez
providers.
○ Partial RFC 6750 Bearer Token support.

@alvaro_sanchez
Roadmap
● Upcoming release: 1.4.1.
○ Complete RFC 6750 Bearer Token support.
○ Due in few days.
● Next release: 2.0.
○ Complete RFC 6749 OAuth 2.0 support.
○ ETA: Q1 2015.

@alvaro_sanchez
Agenda
1. Authentication in monolithic applications vs
microservices.
2. Introduction to OAuth 2.0.
3. Achieving statelessness with JWT.
4. Demo.
5. Q&A.

@alvaro_sanchez
Thanks!
Álvaro Sánchez-Mariscal
Web Architect -
Images courtesy of
@alvaro_sanchez

Stateless authentication for microservices

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Stateless authentication for microservices

Similar to Stateless authentication for microservices (20)

More from Alvaro Sanchez-Mariscal

More from Alvaro Sanchez-Mariscal (20)

Recently uploaded

Recently uploaded (20)

Stateless authentication for microservices