Api security

API Security
Teodor Cotruta
29 June 2016
Author of LDAP Client for Windows, LDAP 3.0 browser
Programming in Java, OpenGL, C/C++, C#/.NET, VB, SQL, UNIX/Windows (20 years)
Integration, SOA, REST/SOAP, Oracle fusion, IBM Crossworlds, Camel, JBoss esb
Various websites: telecom.co.nz (8.5 years)

OS
Hardware /
Infrastructure
API APIAPIAPI API API API API API
Client/User
Application
Security
Security
User/***
Authentication
Authorisation
1$/1hCompany Uni courses
HTTP, TLS, OAuth, WRAP
OpenID Connect, SAML
Federation
Delegation
TOKEN, JSON, JWT, JWS, JWE

API = Application Programming Interface
A set of functions, procedures and tools for building software and applications.
Platform
Hardware
OS
Protocols
API Security Applications Client
WEB 2.0
Cloud (AWS,
Google, MS Azure)
Web
services,
HTTP, HTTPS
Web services
SOA, SOAP, REST
AAA,
Federation
Delegation
Web applications
Rich Internet
Integration
Users
Business apps
B2B
PC, Laptops, Windows Windows API,
.NET, Java
Word, Excel,
MSAccess, Oracle
Users, Other
apps
PC, Sun stations,
IPC V
Unix, Linux Unix POSIX, Motif,
Java
Oracle Users
Mobile Android Android OS Android API, Java,
C
Google app
store, business
app
Users,
applications,
Surveys
Macintosh EL Capitan Carbon, Cocoa
IPhone Apple store
Business apps

Managed and Naked APIs
Managed
API Naked API
Can connect easily
Intranet
Security, documentation, life cycle, intelligence
Manage load, Performance, access

Middleware ESB vs API
Application
API
ESB
Application
API
SOA APIAPI Proxy
API Gateway
SOA
WS
WS
WS
WS
BUSINESS LOGIC
3. Name + Bank account
FAST
SECURE
VISIBLE
SLOW
NOT ACCESSIBLE
PARTIAL LOGIC
2. Account no
1. Name
4. Teo, 1234543

API = Application Programming Interface
Twitter API
Twitter Website

What is API Security?
Security means Safe to do something at a certain location, during a
specified period using some tools and information
API Security means protecting the API against unauthorized access,
use, disclosure, disruption, modification, perusal, inspection, recording
or destruction.
Protecting the applications and the users using the API.

WHEN TO implement security?
https://msdn.microsoft.com/en-us/library/ms995349.aspx#sdl2_topic1_1
Microsoft SDL security dev lifecycle model - 2005
Security build should start along with API build.

HOW TO implement security?
HTTP Authentication
TLS – Transport Layer Security
Identity delegation
OAuth 1.0
OAuth 2.0
Federation, SAML and JWT (jot)
OpenID Connect
JWToken, JWSignature, JWEncryption
Design Patterns and best practices

HTTP Basic Authentication HTTP Digest Authentication
Sends credentials in cleartext over the
wire
A digest derived from the cleartext password
is sent over the wire.
Should be used in conjunction with some
external security systems like TLS
Doesn’t depend on transport-level security
or external security systems.
Only performs authentication Can be used to protect the integrity of the
message, in addition to authentication
User store can store passwords as a
salted hash
User store should store passwords in
cleartext or should store a hash
Basic authentication: Base64Encode (username:password)
Digest authentication: Recommend to store hash (username:password:realm)
HTTP Authentication

TLS = Transport Layer security
One-way TLS, only the server proves its identity to the client; this is mostly
used in e-commerce to win consumer confidence by guaranteeing the
legitimacy of the e-commerce vendor.
Two-way TLS Mutual authentication authenticates the client and the server.
TLS Handshake process
• 4 keys and a master secrete
• Java key store
• If one key leaks, we can get the master secret and all other 3 keys
PFS Perfect forward secrecy enabled by Google in 2011 (gmail, search,
google+)
• Exchange data

Service to verify TLS sites
Qualys SSL Labs https://www.ssllabs.com/ssltest/analyze.html
free online service performs a deep analysis of the configuration of any SSL web server on the public
Internet.

Identity Delegation Model
3 roles (actors)
• delegator, owns the resource
• delegate, wants to access the resource
• service provider (resource server) hosts the protected service, validated the
delegate
Print app
(delegate)
Flickr
Service Provider
Grants privileges
Imports photos
Delegator
Direct delegation
File Editor
Google drive
Resource server
Grants privileges
Export filesGives read privilege
On google drive
Print app Read files
Brokered delegation

Evolution of identity delegation
Up to 2006 (give away username/password)
• Sites were asking username/password on your email accounts to
invite your friends, or SlideShare asked for your google
username/password to use your google calendar.
After 2006
• Google started using tokens

History after 2006 Google uses tokens
Google AuthSub: App doesn’t know username/password
Similar models were used by
• Flickr Authentication API, before 2006
• Yahoo BBAuth similar to flicker
WEB
APP
Google account
Authentication
Authorisation
User
Google services
Request token
Request access
With token
Response with Data
Redirect to app
With TOKEN
Login
page
Access
Y/N

History – Delegation models … + federation
< 2006: Google AuthSub, Yahoo BBAuth, Flickr Authentication
• 2007 OAUTH 1.0 – becomes standard
Similar to Google, Yahoo and Flickr, request token, use token for data
• 2009 OAUTH 2.0
As a result, OAuth 2.0 was developed as an authorization framework,
rather than a standard protocol. OAuth 2.0 became RFC 6749
• 2009 OpenID/OAuth hybrid extension
Integrate OAuth with OpenID, delegation with federation
OpenId is a standard developed by the OpenId Foundation for decentralized single sign-on.
http://openid.net/specs/openid-authentication-2_0.html.
• OpenID Connect

OAUTH 1.0 = Open Authorization
TOKEN
A unique identifier issued by the server and used by the client to associate authenticated requests
with the resource owner whose authorization is requested or has been obtained by the client.
Tokens have a matching shared-secret that is used by the client to establish its ownership of the
token, and its authority to represent the resource owner.
3 PHASES are defined in OAuth 1.0 handshake
1. Temporary-credential request phase
2. Resource-owner authorization phase
3. Token-credential request phase.

OAuth 1.0
Token dance
Simplified 3 steps or phases
1. Credential request TOKEN + SECRET
2. Owner Authorisation: TOKEN + VERIFIER
3. Access token given: ACCESS TOKEN + SECRET
CONSUMER
APP
AUTHORIZATION
SERVER
REQUEST TOKEN
TOKEN
Authenticates
Authorises Token
AUTHORISED REQUEST
TOKEN
PROTECTED
API
ACCESS TOKEN
ACCESS TOKEN
CREDENTIALAUTHORIZATONACCESS
REQUEST ACCESS TOKEN
TOKEN phases
1. TOKEN + SECRET credential
2. TOKEN + VERIFIER authorisation
3. ACCESS TOKEN + SECRET access

OAuth 1.0 = Credential + Authorisation + Access
initial token, verified, new token
• Temporary credential phase: TOKEN + TOKEN SECRET
• Temporary-Credential Request Phase During the temporary-credential request phase, the OAuth client sends
an HTTP POST to the temporary-credential request endpoint hosted in the resource server
• At the end the client has oauth_token and an oauth_token_secret.
• Resource-Owner Authorization Phase: TOKEN + VERIFIER
• During the resource-owner authorization phase, the client must get the oauth_token received in the
previous phase authorized by the user or the resource owner. The client redirects the user to the resource
server with the following HTTP GET request. The oauth_token received in the previous phase is added as a
query parameter. Once the request hits the resource server, the resource server knows the client
corresponding to this token and displays it to the user on its login page.
• The user must authenticate first and then authorize the token.
• To initiate the resource-owner authorization phase, the client must have access to the oauth_token and the
oauth_token_secret. At the end of this phase, the client has a new oauth_token and an oauth_verifier
• Token-Credential Request Phase: NEW TOKEN (ACCESS) AND TOKEN SECRET
• During the token-credential request phase, the client makes a direct HTTP POST or a GET request to the
access-token endpoint hosted at the authorization server
• To initiate the token-credential request phase, the client must have access to the oauth_token from the first
phase and the oauth_verifier from the second phase. At the end of this phase, the client will have a new
oauth_token and a new oauth_token_secret.

OAuth 2.0 Facebook, Google, Instagram, PayPal
OAUTH 2.0: Facebook, Google, LinkedIn, Microsoft (MSN, Live), PayPal, Instagram
OAUTH 1.0: Twitter
WRAP uses the notion of profiles
Client
• The Client Account and Password Profile and
• The Assertion Profile. User
USER DELEGATION PROFILES
• Username and Password Profile: installed trusted apps
APP gets username/password, get a token, store the token for later use
• Web App Profile: verification code then access token
• Rich App Profile: installed app or mixed, mostly mobile
Accessing a WRAP-Protected API
curl –H "Authorization:WRAP
access_token=cac93e1d29e45bf6d84073dbfb460"
http://localhost:8080/recipe

OAuth 2.0
Oauth 2.0 adds two major extension points:
• Grant types
• Authorization code
• Implicit
• Resource owner password credential
• Client credential
• Token types
A grant type defines how a client can obtain an authorization grant from a resource owner to access
a resource on their behalf. The grant types in OAuth 2.0 are very similar to the OAuth profiles in
WRAP
{ "access_token":"ya29.1.AADtN_WY1SHPAYomlwrc", "token_type":"Bearer", "expires_in":3600,
"id_token":"" }

OAuth 1.0 vs. OAuth 2.0
OAuth 1.0 OAuth 2.0 Bearer Token Profile
An access-delegation
protocol
An authorization framework for access
delegation
Signature based: HMAC-
SHA256/RSA-SHA256
Non-signature-based, Bearer Token Profile
Less extensibility Highly extensible via grant types and token
types
Less developer friendly More developer friendly
TLS required only during the
initial handshake
Bearer Token Profile mandates using TLS
during the entire flow
Secret key never passed on
the wire
Secret key goes on the wire (Bearer Token
Profile)

OAUTH 2 Profiles
Built on top of OAUTH 2.0 grant types and token types
• Token Introspection Profile
• Chain Grant Type Profile
• Dynamic Client Registration Profile
• Token Revocation Profile
EXAMPLES
Salesforce revocation token
• curl https://login.salesforce.com/services/oauth2/revoke?
token='00D90000000…Teo4RMT'
• anyone can revoke a token

Federation (Single Sign On, …)
Federation, in the context of API security, is about
Propagating user identities across
• distinct identity-management systems or
• distinct enterprises.
Brokered Authentication
• With brokered authentication, at the time of authentication, the authorization server can
trust a broker from the given domain.
• Each external party should have a trust broker whose responsibility is to authenticate its
own users
Uses OAuth principles, it means four entities in a federation scenario:
• Owner for resource
• Server with resource
• Authorization server
• Client application

Brokered authentication OAuth Client app
YAHOO XTRA
WEB MAIL
Client ID
OAuth
Authorisation
Server
Authorization
code
Trust Broker
authenticate
Signed assertion
Redirects user
Client id +
Signed assertion
OWNER
EMAIL API
(SERVER)
WEB MAIL
Client
Trust
Broker
UK
ACCESS TOKEN
Get email
1
Yahoo website
(SERVER)
2
34
ACCESS TOKEN
1. OWNER Request
2. Redirect
Auth code
3. Authenticate
Assertion
4. Authorise
Access Token
Get Email

SAML (XML), JWT (JSON)
SAML: Security Assertion Markup Language
Standard for exchanging authentication, authorization, and identity-
related data between interested parties in an XML-based data format
Assertions, Protocol (SAML Request/Response), Bindings
Profiles: Web Single Sign-on profile defines a standard way to establish
SSO between different service providers via SAML.
JSON Web Token (JWT) is a well-structured JSON message.
Both profiles address the same use cases.

OpenID Connect = OpenID + OAuth 2.0
• Identity layer built on top of OAuth 2.0
• OpenID Connect: standard February 26, 2014.
• Lightweight framework for identity interactions using REST
• OpenID extension for OAuth 1.0
OpenID + OAuth 1.0 = authentication + delegated authorisation
• OpenID Connect
The ID token is the primary add-on to OAuth 2.0 to support
OpenID Connect

OpenID protocol flow
Relying party
OpenID || OpenID Provider
OpenID Provider
OpenID protocol scenario
1. Enter OpenID on the relying party site
2. Discover the OpenID provider, if not known
3. Shared secret key between the RP and OP
4. User redirected to OpenID provider
5. User has to authenticate
6. Relying party receives a response
7. Relying party checks the response signature
Which should be signed with the secret key
Exchanges between relying party
And the provider including authentication
Of the use on the provider

OpenID Connect
OpenID Connect
Relying party
OpenID Provider
User identifier
ID Token

JWT JWS JWE
JASON Web token
• JSON Web Token (JWT) defines a container to transport data between interested parties in JSON
• The OpenID Connect specification, uses a JWT to represent the ID token.
• Google API is one example
JSON Web Signature
• The JSON Web Signature (JWS) specification, developed under the IETF JOSE working group,
defines how JSON messages can be digitally signed or MACed
JSON Web Encryption
• The JSON Web Encryption (JWE) specification, defines how JSON messages can be encrypted.
• It introduces two new attributes (enc and zip) to be included in the JWE header of an encrypted
JSON payload
First signed, then encrypted

Patterns and practices
Direct Authentication with the Trusted Subsystem Pattern
WEB APP
API
available
LDAP
Federation Single Sign on Pattern
Token dance, OAuth 1.0

Risks and vulnerabilities OWASP
Open Web Application Security Project (OWASP)
There are scanners for
• Injection
• Broken Authentication and Session Management
• Cross Site Scripting
• Insecure Direct Object References
• Security Misconfiguration
• Sensitive Data Exposure
• Missing Function Level Access Control
• Cross Site Request Forgery
• Using Components with Known Vulnerabilities
• Invalidated Redirects and Forwards.
http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202013.pdf

Case studies with examples
Sample Methods in time What has been
used
Pro Cons
Large
website in
NZ
Start with
requirements
Security available
off the self
Siteminder
Sun IDA
Availability of a
known product
Documentation
Team skills ok
Training
available
Hard to maintain (special
team)
High coupling between code
and security, impossible to
change in the future
Desktop
software
distribution
After the fact
Custom made
License model Protects
revenue
Unflexible
Difficult to move from a
machine to another
Desktop
software
distribution
Off the self product License model Protect revenue
Easy to use
Known issues, vulnerable to
attacks.
Web
applications
In house during
development
OAUTH 1.0 Can change at
will
Doesn’t cover all scenarios,
requires patches
Web
applications
Third party
products
Hard to implement
No experience
Industry
standards
In house build None Hard to implement
No experience

CONCLUSION API Security
API meaning has changed in the past decade, meaning apps that are used on the
internet. This can be achieved through SOA, especially REST and JSON.
Security evolved with a number of models, the most important being:
• OpenID Connect
• JWToken, JWSignature, JWEncryption
• Federation, SAML and JWT (jot)
• Identity delegation
• OAuth 2.0 quite equal with OAuth 1.0
• TLS – Transport Layer Security
• HTTP Authentication

Bibliography
1. Advanced API Security, Prabath Siriwardena, apress, 2014
2. OpenID connect: http://openid.net/connect/
3. Securing the API Stronghold, Travis Spencer and all, nordicaps.com, 2015,
http://nordicapis.com/wp-content/uploads/securing-the-api-stronghold.pdf
4. How to control User Identity within microservices
http://nordicapis.com/how-to-control-user-identity-within-microservices/
5. Rest security cheat sheet
https://www.owasp.org/index.php/REST_Security_Cheat_Sheet
6. State of API security
https://www.soapui.org/testing-dojo/world-of-api-testing/state-of-api-
security.html

Api security

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (10)

Similaire à Api security

Similaire à Api security (20)

Dernier

Dernier (20)

Api security