API Gateway & Identity Providers, a Match Made in Microservices Heaven Yaara Letz, Consulting Engineer at Tyk.io

1. API Days workshop
API Gateway &
Identity Providers,
a Match Made in
Microservices
Heaven

2. Yaara Letz
Partner Consulting &&/|| Engineer @Tyk
London, UK
www.linkedin.com/in/yaara-letz-3439ba4
About me

3. Tyk in 1 Minute
API Management Platform:
• API Gateway
• Control Plane
• Developer Portal
• Flexible: SaaS and On-Premises
By engineers for engineers:
• Microservice architecture
• Integration over vendor lock-in
• Go Lang - fast and lean

4. Tyk
Today’s talk
• Set the scene: Privacy, data breaches and keyless APIs
• The Problem: How to prevent those when using APIs in microservices architecture.
• Action: Use API gateway to ease the pain
• Demo: Securing my API with Tyk and external Identity Provider
• Q & A

5. Tyk
Privacy, regulation and Data breaches
Privacy - Personal information is collected
GDPR - General Data Protection Regulation - May 2018
Data breaches – You are liable for the data you hold.
Invest in security today to avoid to avoid reputational and
financial Consequences tomorrow

6. Tyk
Story time –
Domino's Pizza are keeping your data safe

7. Tyk
How does it apply to APIs?
2018, many organisations had their APIs exposed to data breach and cyber attacks:
👺 Facebook
- What: Cambridge Analytica harvested 50M users’ profiles for political adverts
- How: Graph API of early version of FB’s API
👺 Uber
- What: Compromised sensitive information of 57m users
- How: Hackers found login credentials on an insecure private gist
👺 Tinder
- What1: Undocumented APIs leaked location in 2013
- What2: Exposed users’ photos and activities
- How: Didn’t use HTTPS end-to-end and poor encryption HTTPS
https://www.helpnetsecurity.com/2017/11/22/uber-data-breach/
https://qz.com/106731/tinder-exposed-users-locations/
https://www.wired.com/story/tinder-lack-of-encryption-lets-strangers-spy-on-swipes/

8. Tyk
APIs are vulnerable too
Gartner, 2017:
By 2022, Data breaches in enterprises will be mainly in web
applications space and by API abuses attacks

9. Tyk
Let’s talk about Keyless APIs
1. What is a keyless API?
2. When do people use keyless APIs
3. Is it dangerous? Why?
4. How can we address it?

10. Tyk
Keyless APIs - unofficial definition
• An unprotected API – open for everyone, public
• No need for key/token/password/identifying details
• Its consumer is unidentified and unlimited

11. Tyk
When do I use keyless APIs
• For internal usage (hint: trust model L bad decision)
• When I want everyone to access my APIs
• When I want barriers-free access to drive adoption of my API
• When I don’t need to know who is accessing my APIs
• When my APIs provide access to an already freely available data
• When I “only” serve data
So what is the danger?

12. Tyk
What is the danger?
è The temptation:
You have static website…
…just for reading…
…only does a simple HTTP GETs…
…I don’t need to know who’s using my APIs
è Implicit trust
è This is an opportunity for an attacker to
exploit!

13. Tyk
What are the risks of keyless APIs?
• Back door - Give the world direct access to your code
• In case of a bug -
Expose your services to malicious access
Worse – expose your clients data ( remember Gartner prediction?)
• No rate limit and quota –
Degrade API performance for everyone – noisy neighbour (bad code, load test)
Results in an overloaded API service and increased cloud consumption
• No identity
You can’t identify the abuser and block his API calls.
Lost business opportunity - can’t to use clients’ details to build your business and it’s hard
to segment your API traffic by users
So what should I do?

14. Tyk
Even Google stopped using keyless API (June 2018)
{
"error_message" : "Keyless access to Google
Maps Platform is deprecated. Please use an
API key with all
your API calls to avoid
service interruption.
For
details please
refer to http://g.co/dev/no-account",
"status" : "OVER_QUERY_LIMIT"
}

15. Tyk
How Do I Drive Innovation While Still Protecting Keyless APIs?

16. Tyk
à With An API gateway

17. Tyk
Front Keyless APIs with an API gateway (or implement yourself) :
if (you do):
• Leave only necessary endpoints
• Set a global rate limiting and throttling
• Use common headers for user identification, rate-
limiting, quota capping, tracing and analytics
(User-Agent, X-Real-IP, Authorization)
then (you will):
• Avoid overloading of your API
• Avoid cloud consumption
• Gather analytics and ability to do user
segmentation
• Identify and block abusers
else – next slide

18. Tyk
Let’s summaries the risks we are facing with APIs
1. Data breaches on poorly protected APIs (MITM)
2. Cyber attacks on poorly designed flows (Session Cookie Tampering, DDoS)
3. Leaked information via poorly designed APIs (TLS, API Parameter Tampering)
4. Degrade in all of my services and spike of my cloud consumption (Noisy neighbour)
5. Abusing the trust model (User’s ID can be compromised)

19. Tyk
The goal – basically prevention
• Prevent the next data breach
• Avoid data leaking (which can happen in every new release)
• Protect your APIs from abuse by innocent or not so innocent caller
• Keep metrices on the users in case of a breach or attack
Security approach should be a balance between exposing web APIs in approachable way
to ensure adoption with control to prevent abuse or attacks.

20. Tyk
à An API gateway can help – Duh #2

21. Tyk
How Can Tyk Help?
1. Authentication + Authorization – to identify and approve the caller
2. Throttle, Quota and Rate Limit users, apps and APIs - protect from abuse, brute force
attack and noisy neighbours
3. Policies - to enforce tiered, metered and granular user access per path and method
4. Metrices – analytics per key, per API, or per request
5. lots more - versioning, clean leaking data, json validation, help SQL injection, backend
protection (mTLS, Certificate pinning, RSA sign RSA request to upstream)…

22. Tyk
Apply AuthN and
AuthZ To
Microservices

23. Tyk
Why Microservices – A Quick Touchbase
• Reduced coordination
• Fast onboarding new joiners
• Flexibility in development and deployment
• Compatible with modern approaches
• Reduced risk with no single point of failure

24. Tyk
AuthN and AuthZ Definitions
• Authentication is the process through which a client proves their identity to the server
• Authorisation is the server controlling what actions a specific identified client is able to
perform

25. Tyk
Options For Adding AuthN and AuthZ To Microservice
1. Internally within each microservice
2. Externally by a gateway
3. Combination of internal and external
4. Wait-and-see

26. Tyk
Microservices - internal approach
Pros:
• Gives fined grained control
• Self-reliance
Cons:
• More development effort
• Complicates the code
• Larger microservices
• Repeated code - Risk of Copy/paste code
• Will probably not cover all aspects or new ones
• Not visible to security team
Gartner suggest – “Don not code API security policies into the APIs”

27. Tyk
Microservices - external approach
Pros:
• Centrally handled
• Enforce AuthN and AuthZ
• Less development effort
• Smaller microservices
• Flexible with configuration
Cons:
• Vulnerability – circumvent the gateway à sort with mTLS and network set up
• Less control – when needs DB to decide AuthZ à use Tyk as TCP proxy

28. Tyk
Microservices - combined approach
Pros:
• Relieves burden of
authentication
• Gives control of authorisation
(for complex decisions)
Cons:
• More development effort
• Larger microservices
• Repeated code

29. Tyk
Choosing the right AuthN + AuthZ Methods
✔ Regulations industry
✔ Consistency
✔ Scenarios
✔ Users’ directory

30. Tyk
Identity providers
Central hub for all of your identity needs:
- Authentication – standards and protocols
- Single Sign-On (SSO) - in the intranet and internet
- Multi-factor authentication (MFA) - emails OTP, SMS, USB key etc.
- Federation identity and multiple user’s identities

31. Tyk
Forth approach – With An Identity Providers
You don’t have to on-board all the existing keys just
let a the IdP to manage the user identity for you

32. Tyk
Using a
proprietary
signed generic
JWT
Demo 2: Securing an API

33. Tyk
Conclusion
There is no single best solution
I’d favour the “external” approach –
ü Use an API gateway to offload and simplify and centralise AuthN and AuthZ trivial flows
ü Use an IdP to offload identity management and maintenance from your code and your
data stores
ü You can focus on your core business
Mental note for future talk J – discuss AuthN/AuthZ requirement and setup for service
mesh "east-west" traffic and not via the Edge API gateway.

34. Tyk

35. Tyk
Q & A
Yaara Letz @yaarale
twitter.com/tyk_io
github.com/TykTechnologies
facebook.com/Tyk.API.Management