challenges and best practices in securing apis
TRANSCRIPT
Challenges and Best Practices in Securing APIs
Dulanja Liyanage Associate Technical Lead
Isura KarunaratneSenior Software Engineer
Attributes of a secured design
Authentication Only legitimate users can access the system
Authorization The system won’t allow users to do anything more than what they are supposed to do
Confidentiality Confidential data can only be seen by the intended recipients, nobody else
Integrity Integrity of the transactions are protected
Non-repudiation An entity cannot deny its actions
Availability The system is available for legitimate users to access, all the time
HTTP Basic Authentication
• Creating a GitHub repository
curl -I-u $GitHubUserName:$GitHubPassword -X POST -H 'Content-Type: application/x-www-form-urlencoded’-d '{"name": "my_github_repo"}' https://api.github.com/user/repos
Authorization: Basic QWxhZGRpbjpPcGVuU2VzYW1l
HTTP Digest Authentication
curl -k --digest --u username:password -v https://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 UnauthorizedWWW-Authenticate: Digest realm="cute-cupcakes.com", qop="auth”, nonce="1390781967182:c2db4ebb26207f6ed38bb08eeffc7422", opaque="F5288F4526B8EAFFC4AC79F04CA8A6ED"
HTTP Basic vs. Digest Authentication
Basic Authentication Digest Authentication
Sends credentials in clear text Credentials 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 authentication Can perform authentication and integrity protection (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
TLS Mutual Authentication
curl -k --cert client.pem https://localhost:8443/recipe
▪ Gateway itself does the certificate validation▪ Fine-grained access validations can be done by the authorization server
OAuth• Allows applications to act on behalf of end users without sharing
credentials
e.g. Posting a YouTube video to the FB timeline.
• OAuth 1.0a– Restrictive, cumbersome, involves signatures– Only twitter uses it
• OAuth 2.0– Depends on SSL/TLS– A framework rather than a concrete standard
– Could cater many use cases - via grant types
❖ Roles❖ Resource Owner❖ Resource Server❖ Client Application❖ Authorization Server
OAuth 2.0
• Three-legged OAuth– Client, Resource Server and User (Resource Owner)
• Two-legged OAuth– Client (Resource Owner) and Resource Server
OAuth
Authorization Code GrantSuitable for web applications.
Implicit GrantSuitable for mobile, SPA and untrusted public apps where client secret cannot be kept private.
Resource Owner Credentials GrantSuitable for apps trusted by Authz Server. e.g. official FB app.
Client Credentials GrantSuitable to retrieve data not specific to end users - e.g. Weather/Stocks - and for machine-to-machine communications.
OAuth 2.0
OAuth 2.0 - Authorization Code Grant
OAuth 2.0 - Decoupling End User Authentication from the Authorization Server
OAuth 2.0 - SAML Grant Type
OAuth 2.0 - JWT Grant Type
OAuth 2.0 - NTLM Grant Type
OAuth 2.0 - Chained Grant Type
Token Introspection
POST /introspection HTTP/1.1Accept: application/x-www-form-urlencodedHost: server.example.comAuthorization: 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/*}
Standardization of Resource Server -> Authorization Server communication for token validation
Fine-grained Authorization with XACML
User-Managed Access (UMA)
• OAuth 2.0 solves Person-to-Client delegation
• UMA tries to solve/standardize Person-to-Person delegation
e.g. Luke sharing a doc on Google Drive with ‘edit’ rights to John and ‘view’ rights to Peter
• Introduces an entity named “Requesting Party”
• IoT have quite interesting scenarios UMA could solve.
User-Managed Access (UMA)
Confidentiality: • TLS, JWE
Integrity: • TLS, JWS
Non-repudiation: • JWS
Availability: • Network level measures• Throttling: Client level, User level
Questions?