Businesses today are rapidly moving from being service enabled to being API enabled. Moving into the world of APIs brings with it its own set of complexities and challenges that are tough to tackle. API security is a key area to be focusing your engineering efforts on. This talk will focus on various security protocols that are available and on leveraging the extensive feature set and extensible nature of the WSO2 platform to secure your APIs.

1. Securing Your APIs:
How, What, Why and When
Dulanja Liyanage
Technical Lead, WSO2
dulanja@wso2.com

2. A:ributes of a secured design
Authen>ca>on Only legi>mate users can access the system
Authoriza>on The system won’t allow users to do anything
more than what they are supposed to do
Confiden>ality Confiden>al data can only be seen by the
intended recipients, nobody else
Integrity Integrity of the transac>ons are protected
Non-repudia>on An en>ty cannot deny its ac>ons
Audi>ng All anomalies are recorded
Availability The system is available for legi>mate users to
access, all the >me

3. HTTP Basic Authen?ca?on
• Crea?ng a GitHub repository
curl -I
-u $GitHubUserName:$GitHubPassword
-X POST -H 'Content-Type: applica>on/x-www-form-urlencoded’
-d '{"name": "my_github_repo"}'
hYps://api.github.com/user/repos
Authorization: Basic QWxhZGRpbjpPcGVuU2VzYW1l

4. HTTP Digest Authen?ca?on
curl -k --digest --u username:password -v hYps://localhost:8443/recipe
Authorization: Digest username="prabath", realm="cute-
cupcakes.com",
nonce="1390781967182:c2db4ebb26207f6ed38bb08eeffc7422", uri="/
recipe", cnonce="MTM5MDc4", nc=00000001, qop="auth",
response="f5bfb64ba8596d1b9ad1514702f5a062",
opaque="F5288F4526B8EAFFC4AC79F04CA8A6ED"
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest realm="cute-cupcakes.com", qop="auth”,
nonce="1390781967182:c2db4ebb26207f6ed38bb08eeffc7422",
opaque="F5288F4526B8EAFFC4AC79F04CA8A6ED"

5. HTTP Basic vs. Digest Authen?ca?on
Basic Authen?ca?on Digest Authen?ca?on
Sends creden>als in clear text Creden>als never sent in clear text. A
digest derived is sent
Must be used with a transport level
security like TLS
Does not depend on transport level
security
Only performs authen>ca>on Can perform authen>ca>on and
integrity protec>on (with qop=auth-int)
User store can store password as a
salted hash
User store should store password in
cleartext or store the hash value of
username:password:realm

6. TLS Mutual Authen?ca?on
curl -k --cert client.pem h:ps://localhost:8443/recipe
• Gateway itself does the cer>ficate valida>on
• Fine-grained access valida>ons can be done by the authoriza>on server

7. OAuth
• Allows applica?ons to act on behalf of end users without sharing
creden?als
• Three-legged OAuth
– Client, Resource Server and User (Resource Owner)
• Two-legged OAuth
– Client (Resource Owner) and Resource Server
• OAuth 1.0a
– Restric>ve, cumbersome, involves signatures
– Only twiYer uses it
• OAuth 2.0
– Depends on SSL
– A framework rather than a concrete standard
– Could cater many use cases - via grant types

8. Authoriza?on Code Grant
Suitable for web applica>ons.
Implicit Grant
Suitable for mobile, SPA and untrusted public apps where client secret cannot be
kept private.
Resource Owner Creden?als Grant
Suitable for apps trusted by Authz Server. e.g. official FB app.
Client Creden?als Grant
Suitable to retrieve data not specific to end users - e.g. Weather/Stocks - and for
machine-to-machine communica>ons.
OAuth 2.0

9. OAuth 2.0 - Authoriza?on Code Grant

10. OAuth 2.0 - Decoupling End User Authen?ca?on from
the Authoriza?on Server

11. OAuth 2.0 - SAML Grant Type

12. OAuth 2.0 - JWT Grant Type

13. OAuth 2.0 - NTLM Grant Type

14. OAuth 2.0 - Chained Grant Type

15. Token Introspec?on
POST /introspection HTTP/1.1
Accept: application/x-www-form-urlencoded
Host: server.example.com
Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3
token=X3241Affw.4233-99JXJ&resource_id=…
{
"active": true,
"client_id":"s6BhdRkqt3",
"scope": "read write dolphin",
"sub": "2309fj32kl",
"aud": http://example.org/protected-resource/*
}
Standardiza>on of Resource Server -> Authoriza>on Server communica>on
for token valida>on

16. Fine-grained Authoriza?on with XACML

17. User-Managed Access (UMA)
• OAuth 2.0 solves Person-to-Client delega>on
• UMA tries to solve/standardize Person-to-Person
delega>on
e.g. Luke sharing a doc on Google Drive with ‘edit’
rights to John and ‘view’ rights to Peter
• Introduces an en>ty named “Reques>ng Party”
• IoT have quite interes>ng scenarios UMA could solve.

18. User-Managed Access (UMA)

19. Confiden?ality:
• TLS, JWE
Integrity:
• TLS, JWS
Non-repudia?on:
• JWS
Audi?ng:
• Audit logs
• Analy>cs for fraud/threat detec>on
Availability:
• Network level measures
• ThroYling: Client level, User level

20. Thank You!
#WSO2ConEU
Share your feedback for this session
wso2con.com/app