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

OAuth 2.0: protocol flow Hey, backend, could you please give me a list of games? @alvaro_sanchez

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

OAuth 2.0: protocol flow Hi Google, can I get an access token please? Backend is asking @alvaro_sanchez

OAuth 2.0: protocol flow Sure thing sir. I just need to ask a few details to @alvaro_sanchez the user first

OAuth 2.0: protocol flow Hi, could you please provide me your credentials? I need to verify your identity @alvaro_sanchez

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

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

OAuth 2.0: protocol flow Hi Backend, this is my token: qfE2KhvKggluHqe7IpTBqZ4qziTQQbKa @alvaro_sanchez

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

OAuth 2.0: protocol flow Of course. That token is still valid and it belongs to @alvaro_sanchez bob@gmail.com.

OAuth 2.0: protocol flow Everything is allright. This is the list of games. @alvaro_sanchez Enjoy!

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

OAuth 2.0: protocol flow 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

Authorization code grant http://myServerApp.com @alvaro_sanchez

Authorization code grant 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

Authorization code grant hhttttpp::////fmacyeSbeorvoekr.Acopmp.com @alvaro_sanchez

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

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

Authorization code grant 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_id=YOUR_CLIENT_ID &client_secret=YOUR_CLIENT_SECRET @alvaro_sanchez

Authorization code grant 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 &client_id=YOUR_CLIENT_ID &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

Password credentials grant @alvaro_sanchez

Password credentials grant POST request to: https://api.example. org/oauth/access_token With this body: grant_type=password &username=USERNAME&password=PASSWORD &client_id=YOUR_CLIENT_ID &client_secret=YOUR_CLIENT_SECRET @alvaro_sanchez

Password credentials grant Example response: { "access_token": "RsT5OjbzRn430zqMLgV3Ia", "token_type": "Bearer", "expires_in": 3600, "refresh_token": "e1qoXg7Ik2RRua48lXIV" @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

Client credentials grant POST request to: https://api.example. org/oauth/access_token With this body: grant_type=client_credentials &client_id=YOUR_CLIENT_ID &client_secret=YOUR_CLIENT_SECRET @alvaro_sanchez

Client credentials grant Example response: { "access_token": "RsT5OjbzRn430zqMLgV3Ia", "token_type": "Bearer", "expires_in": 3600, "refresh_token": "e1qoXg7Ik2RRua48lXIV" @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

In this document

More Related Content

What's hot

Similar to Stateless authentication for microservices

More from Alvaro Sanchez-Mariscal

Recently uploaded

Stateless authentication for microservices