Slides from my talk on MuCon London 2016 about authentication options for microservice-style software systems

1. @davib0
Authentication in Microservice Systems
David Borsos

2. @davib0
Authentication and Authorisation in
Microservice Systems
David Borsos

3. @davib0
Authentication and Authorisation in
Microservice Systems
David Borsos

4. @davib0
End-user
Authentication and Authorisation in
Microservice Systems
David Borsos

5. @davib0
Introduction
David Borsos
Joined OpenCredo in 2013
Working on microservices since then
Email: david.borsos@opencredo.com
Twitter: @davib0
http://www.opencredo.com

6. @davib0
Why?

7. @davib0
Traditional “monolithic” architecture

8. @davib0
Traditional “monolithic” architecture

9. @davib0
Traditional “monolithic” architecture

10. @davib0
μServices!

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

12. @davib0
μServices

13. @davib0
μServices - Let’s try the same pattern

14. @davib0
μServices - Let’s try the same pattern
Problem #1 - shared user database

15. @davib0
μServices are distributed

16. @davib0
μServices
Problem #1 - shared user database

17. @davib0
μServices
Problem #1 - shared user database
Solution #1 - distribute!

18. @davib0
μServices
Problem #1 - shared user database
Solution #1 - distribute!
Problem #2 - who owns the credentials?

19. @davib0
Single Responsibility

20. @davib0
μServices
Problem #1 - shared user database
Solution #1 - distribute!
Problem #2 - who owns the credentials?

21. @davib0
μServices
Problem #1 - shared user database
Solution #1 - distribute!
Problem #2 - who owns the credentials?
Solution #2 - Authentication Service

22. @davib0
μServices
Problem #1 - shared user database
Solution #1 - distribute!
Problem #2 - who owns the credentials?
Solution #2 - Authentication Service
Problem #3 - switching services

23. @davib0
Authenticate every time?

24. @davib0
Obviously not

25. @davib0
Aiming for transparency
vs.

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

27. @davib0
μServices
1. Use SSO solutions
2. Distributed session
3. Client-side token
4. Client-side token + API Gateway

28. @davib0
1. Using SSO

29. @davib0
Detour: how do these work?

30. @davib0
A common SSO pattern
1. 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 Application maintains “local login”

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

32. @davib0
Using SSO solutions
Security 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 ✘

33. @davib0
2. Distributed sessions

34. @davib0
Distributed sessions
1. User requests access
2. Not authenticated
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

35. @davib0
Distributed sessions
Security 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 !

36. @davib0
3. Client-side tokens

37. @davib0
3. “Poor man’s certificates”

38. @davib0
Client side tokens
1. User requests access
2. Not authenticated
3. User authenticates with Auth Server
4. Authentication successful
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

39. @davib0
Detour: JSON Web Tokens (JWT)

40. @davib0
JWT
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzd
WIiOiJteVVzZXJJZCIsIm5hbWUiOiJKb2huIERv
ZSJ9.00q6RI76-oOyQIoshomTVIfmebQPGoDV
2znTErEJjjo
Header
{
"alg": "HS256",
"typ": "JWT"
}
Body
{
"sub": "myUserId",
"name": "John Doe"
}
Signature

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

42. @davib0
Client side tokens
1. User requests access
2. Not authenticated
3. User authenticates with Auth Server
4. Authentication successful
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

43. @davib0
But...

44. @davib0
...token is valid until TTL...

45. @davib0
...and μServices accept it...

46. @davib0
… so, logout?

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

48. @davib0
Client-side tokens
Security 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 ✔
Integration Good library support ✔
Implementation Simple ✔

49. @davib0
4. Client-side tokens
+
API Gateway

50. @davib0
Client-side tokens + API Gateway
1. User requests access
2. Not authenticated
3. User authenticates with Auth Server
4. Authentication successful
a. Set ID token on the client side
i. Self-contained
ii. Signed
iii. TTL
5. API Gateway translates to opaque token
6. API Gateway resolves to ID token
7. Services understand ID token
a. Can parse user ID
b. Can verify token
i. Check signature
ii. Check TTL

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

52. @davib0
Client-side tokens + API Gateway
Security 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 !
Integration Good library support ✔
Implementation Fairly high complexity ✘

53. @davib0
Summary

54. @davib0
SSO Distributed Session JWT API GW
Security ✔ ✔ ! ✔
Secret sharing ✔ ✘ ! !
Statelessness ✘ ✔ ✔ !
SPOF @ service
switch
✘ ! ✔ ✔
Bottlenecks ! ✘ ✔ !
Transparent ✔ ✔ ✔ ✔
Logout ✘ ✔ ! ✔
Technologies ✔ ✘ ✔ !
Integration ✔ ✘ ✔ ✔
Implementation ✘ ! ✔ ✘

55. @davib0
Email: david.borsos@opencredo.com
Twitter: @davib0
http://www.opencredo.com
Questions?