When implementing applications using a microservice architecture, concerns of authenticating and authorising end-users or other services requires a different approach, especially when scalability and no single points of failure is in mind. I’d like to talk about some “lessons learned” in the past few years and show a few ideas how to deal with these concerns. About David Borsos David is a Senior Consultant for OpenCredo having joined the company as a consultant in 2013. David works on a number of technical engagements for OpenCredo and has a several years experience working in the financial industry, developing web-based enterprise applications, mostly of internally used tools that supported the maintenance and operations of a large IT infrastructure.

1. Authentication and Authorisation in
Microservice Systems
David Borsos

2. Authentication and Authorisation in
Microservice Systems
David Borsos

3. End-user
Authentication and Authorisation in
Microservice Systems
David Borsos

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

5. Why?

6. Traditional “monolithic” architecture

7. Traditional “monolithic” architecture

8. Traditional “monolithic” architecture

9. μServices!

10. μServices!
● Composing functionality
● Self-contained services
● “Bounded context”
● Independent scaling
● Independent deployment
○ Containers
○ Schedulers
■ Kubernetes
■ Mesos + Marathon

11. μServices

12. μServices - Let’s try the same pattern

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

14. μServices are distributed

15. μServices
Problem #1 - shared user database

16. μServices
Problem #1 - shared user database
Solution #1 - distribute!

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

18. Single Responsibility

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

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

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

22. Authenticate every time?

23. Obviously not

24. Transparency
vs.

25. μ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

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

27. 1.Using SSO

28. Detour: how do these work?

29. SSO mechanism
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 μServices maintain local “login”

30. 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

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

32. 2. Distributed sessions

33. 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

34. 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 !

35. 3. Client-side tokens

36. 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

37. Detour: JSON Web Tokens (JWT)

38. JWT
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzd
WIiOiJteVVzZXJJZCIsIm5hbWUiOiJKb2huIERv
ZSJ9.00q6RI76-
oOyQIoshomTVIfmebQPGoDV2znTErEJjjo
Header
{
"alg": "HS256",
"typ": "JWT"
}
Body
{
"sub": "myUserId",
"name": "John Doe"
}
Signature

39. 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

40. 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

41. But wait...

42. ...token is valid until TTL...

43. ...and μServices accept it...

44. … so, logout?

45. 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

46. 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 ✔

47. 4. Client-side tokens
+
API Gateway

48. 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

49. 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

50. 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 ✘

51. Summary

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

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