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?