microservices manchester: authentication in microservice systems by david borsos

Authentication and Authorisation in Microservice Systems

David Borsos

End-userAuthentication and Authorisation in

Microservice SystemsDavid Borsos

Introduction

David Borsos

With OpenCredo since 2013

Working on microservices since then

Email: [email protected]

Twitter: @davib0

http://www.opencredo.com

mailto:[email protected]

http://www.opencredo.com/

Traditional “monolithic” architecture

μServices!

μServices!

● Composing functionality

● Self-contained services

● “Bounded context”

● Independent scaling

● Independent deployment

○ Containers

○ Schedulers

■ Kubernetes

■ Mesos + Marathon

○ PaaS(es)

■ CloudFoundry

● Localized failures

● Prefer statelessness

○ Don’t rely on HTTP Sessions

μServices

μServices - Let’s try the same pattern

μServices - Let’s try the same patternProblem #1 - shared user database

μServices are distributed

μServicesProblem #1 - shared user database

μServicesProblem #1 - shared user databaseSolution #1 - distribute!


Problem #2 - who owns the credentials?

Single Responsibility


Problem #2 - who owns the credentials?


Problem #2 - who owns the credentials?Solution #2 - Authentication Service


Problem #2 - who owns the credentials?Solution #2 - Authentication Service

Problem #3 - switching services

Authenticate every time?

Obviously not

Transparency

vs.

μServices - what do we want?● “Secure”

○ Security is complex (Nicki’s talk)

○ Client-side

○ Sharing secrets?

● Stateless services

○ Multiple instances

● No single point of failure

○ On every request

○ When switching services

● No inherent bottlenecks

● Transparent login

● Ability to log out

● Integration with μServices

● Simple to implement

μServices

1. Use SSO solutions

2. Distributed session

3. Client-side token

4. Client-side token + API Gateway

1.Using SSO

Detour: how do these work?

SSO mechanism1. User requests access

2. Not authenticated

3. User authenticates with SSO Server

4. Authentication successful, grant token

5. User uses token

6. Application uses token to get user details

7. Auth Server returns details

+1 Auth server maintains global “login”

+2 μServices maintain local “login”

Using SSO solutions● SSO “login” state is usually opaque

● SSO Service becomes SPOF

● Chatty traffic

● Every switch potentially requires SSO

○ Optimise with local “login” caching

Using SSO solutionsSecurity As good as the chosen SSO ✔

Secret sharing No ✔

Statelessness Relies on HTTP sessions ✘

SPOF @ service switch Authentication server ✘

Bottlenecks Authentication server (switch only) !

Transparent Yes ✔

Logout Complex ✘

Technologies CAS, OAuth2* ✔

Integration Good library support ✔

Implementation Fairly high complexity ✘

2. Distributed sessions

Distributed sessions1. User requests access


3. User authenticates with Auth Service

4. Authentication successful

a. Write state to distributed Session Store

i. User X is logged in

ii. Sets TTL

b. Sets Session ID on client side

5. User uses Session ID

6. μService read distributed Session Store

a. Refresh TTL

Distributed sessionsSecurity Opaque, rotatable Session ID ✔

Secret sharing Access to session store ✘

Statelessness Shared state ✔

SPOF @ service switch Session store* !

Bottlenecks Session store (every request) ✘

Transparent Yes ✔

Logout Trivial - delete shared session ✔

Technologies Redis, Cassandra, Hazelcast, Riak ✘

Integration Custom implementation ✘

Implementation Medium/High complexity !

3. Client-side tokens

Client side tokens1. User requests access


3. User authenticates with Auth Server


a. Set ID token on the client side

i. Self-contained

ii. Signed

iii. TTL

5. Services understand ID token

a. Can parse user ID

b. Can verify token

i. Check signature

ii. Check TTL

Detour: JSON Web Tokens (JWT)

JWTeyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJteVVzZXJJZCIsIm5hbWUiOiJKb2huIERvZSJ9.00q6RI76-oOyQIoshomTVIfmebQPGoDV2znTErEJjjo

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

Body{ "sub": "myUserId", "name": "John Doe"}

Signature

JWT

● Standard

● Simple

● Extensible

● Can use a variety of signatures (SHA or RSA)

● Good library support

● Symmetric or Public/Private key signatures

● http://jwt.io

http://jwt.io/

Client side tokens1. User requests access





i. Self-contained

ii. Signed

iii. TTL



b. Can verify token

i. Check signature

ii. Check TTL

But wait...

...token is valid until TTL...

...and μServices accept it...

… so, logout?

Client-side tokens: Logout

● Remove token from client-side store

● Periodically check with Auth Service (“renew token”)

● CRL-style revocation

○ Maintain list of revoked tokens

○ Distribute list across μServices (messaging middleware)

● Use short-lived (15m) tokens

Client-side tokensSecurity Potentially exposing User IDs !

Secret sharing Depends on signature algorithm !

Statelessness Completely stateless ✔

SPOF @ service switch None ✔

Bottlenecks None ✔

Transparent Yes ✔

Logout Complex* (for server-side) !

Technologies JWT, OpenID Connect ✔


Implementation Simple ✔

4. Client-side tokens+

API Gateway

Client-side tokens + API Gateway1. User requests access





i. Self-contained

ii. Signed

iii. TTL

5. API Gateway translates to opaque token

6. API Gateway resolves to ID token



b. Can verify token

i. Check signature

ii. Check TTL

API Gateways

● Proxying all user-facing communication

● Fairly simple

● Needs data store

● Not a distributed session

○ μServices don’t interact with token store

○ μServices are not API Gateway-aware

● Logout

○ Revoke tokens in API Gateway’s token store

Client-side tokens + API GatewaySecurity Opaque, rotatable Session ID ✔

Secret sharing Depends on signature algorithm !

Statelessness Some state held in API GW !

SPOF @ service switch None ✔

Bottlenecks API Gateway !

Transparent Yes ✔

Logout Trivial ✔

Technologies JWT, nginx, distributed DB, Kong !


Implementation Fairly high complexity ✘

Summary

SSO Distributed Session JWT API GW

Security ✔ ✔ ! ✔

Secret sharing ✔ ✘ ! !

Statelessness ✘ ✔ ✔ !

SPOF @ service switch

✘ ! ✔ ✔

Bottlenecks ! ✘ ✔ !

Transparent ✔ ✔ ✔ ✔

Logout ✘ ✔ ! ✔

Technologies ✔ ✘ ✔ !

Integration ✔ ✘ ✔ ✔

Implementation ✘ ! ✔ ✘

Email: [email protected]

Twitter: @davib0

http://www.opencredo.comQuestions?

mailto:[email protected]

http://www.opencredo.com/

microservices manchester: authentication in microservice systems by david borsos

Technology