mucon 2016: authentication in microservice systems by david borsos

@davib0

Authentication in Microservice SystemsDavid Borsos

@davib0

Authentication and Authorisation in Microservice Systems

David Borsos

@davib0

End-userAuthentication and Authorisation in

Microservice SystemsDavid Borsos

@davib0

Introduction

David Borsos

Joined OpenCredo in 2013

Working on microservices since then

Email: [email protected]

Twitter: @davib0

http://www.opencredo.com

mailto:[email protected]



@davib0

Why?

@davib0

Traditional “monolithic” architecture

@davib0

μServices!

@davib0

μ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

@davib0

μServices

@davib0

μServices - Let’s try the same pattern

@davib0

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

@davib0

μServices are distributed

@davib0

μServicesProblem #1 - shared user database

@davib0

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

@davib0


Problem #2 - who owns the credentials?

@davib0

Single Responsibility

@davib0


Problem #2 - who owns the credentials?

@davib0


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

@davib0


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

Problem #3 - switching services

@davib0

Authenticate every time?

@davib0

Obviously not

@davib0

Aiming for transparency

vs.

@davib0

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

○ Security is complex○ Client-side○ Sharing secrets?

● Stateless services○ Multiple instances

● No single point of failure○ On every request○ When switching services

● No inherent bottlenecks● Transparency● Logout?● Integration with μServices● Simple to implement

@davib0

μServices1. Use SSO solutions2. Distributed session3. Client-side token4. Client-side token + API Gateway

@davib0

1. Using SSO

@davib0

Detour: how do these work?

@davib0

A common SSO pattern1. User requests access2. Not authenticated3. User authenticates with SSO Server4. Authentication successful, grant token5. User uses token6. Application uses token to get user details7. Auth Server returns details

+1 Auth server maintains “global login”

+2 Application maintains “local login”

@davib0

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

@davib0

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 ✘

@davib0

2. Distributed sessions

@davib0

Distributed sessions1. User requests access2. Not authenticated3. User authenticates with Auth Service4. Authentication successful

a. Write state to distributed Session Storei. User X is logged inii. Sets TTL

b. Sets Session ID on client side5. User uses Session ID6. μService read distributed Session Store

a. Refresh TTL

@davib0

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 !

@davib0

3. Client-side tokens

@davib0

3. “Poor man’s certificates”

@davib0

Client side tokens1. User requests access2. Not authenticated3. User authenticates with Auth Server4. Authentication successful

a. Set ID token on the client sidei. Self-containedii. Signediii. TTL

5. Services understand ID tokena. Can parse user IDb. Can verify token

i. Check signatureii. Check TTL

@davib0

Detour: JSON Web Tokens (JWT)

@davib0

JWTeyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJteVVzZXJJZCIsIm5hbWUiOiJKb2huIERvZSJ9.00q6RI76-oOyQIoshomTVIfmebQPGoDV2znTErEJjjo

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

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

Signature

@davib0

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

http://jwt.io

@davib0

Client side tokens1. User requests access2. Not authenticated3. User authenticates with Auth Server4. Authentication successful


5. Services understand ID tokena. Can parse user IDb. Can verify token


@davib0

But...

@davib0

...token is valid until TTL...

@davib0

...and μServices accept it...

@davib0

… so, logout?

@davib0

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

@davib0

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 ✔

@davib0

4. Client-side tokens+

API Gateway

@davib0

Client-side tokens + API Gateway1. User requests access2. Not authenticated3. User authenticates with Auth Server4. Authentication successful


5. API Gateway translates to opaque token6. API Gateway resolves to ID token7. Services understand ID token

a. Can parse user IDb. Can verify token


@davib0

API Gateways● Proxying all user-facing communication● Fairly simple● Needs data store (for this use-case)● 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

@davib0

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 ✘

@davib0

Summary

@davib0

SSO Distributed Session JWT API GW

Security ✔ ✔ ! ✔

Secret sharing ✔ ✘ ! !

Statelessness ✘ ✔ ✔ !

SPOF @ service switch

✘ ! ✔ ✔

Bottlenecks ! ✘ ✔ !

Transparent ✔ ✔ ✔ ✔

Logout ✘ ✔ ! ✔

Technologies ✔ ✘ ✔ !

Integration ✔ ✘ ✔ ✔

Implementation ✘ ! ✔ ✘

@davib0

Email: [email protected]

Twitter: @davib0


Questions?

mailto:[email protected]



mucon 2016: authentication in microservice systems by david borsos

Technology