Microservices Manchester: Authentication in Microservice Systems by David Borsos
Download as PPTX, PDF7 likes2,240 views
The document discusses authentication and authorization challenges in microservice architectures, highlighting issues like shared user databases and credential ownership. It outlines possible solutions such as Single Sign-On (SSO), distributed sessions, client-side tokens, and the use of API gateways. Each method's pros and cons regarding security, statelessness, and implementation complexity are presented, emphasizing the importance of choosing the right approach for effective microservice security.
Microservices Manchester: Authentication in Microservice Systems by David Borsos
- 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?
- 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
- 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?
- 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
- 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 ✘
- 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 !
- 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 ✘ ! ✔ ✘