HTTP Services Security

Taiseer JoudehCorporate IT Manager at Aramex

@tjoudeh http://bitoftech.net

Agenda• Why we are building HTTP Services?

• Should I care about HTTP Service Security?

• Live examples of Sloppy HTTP Services and Apps.

• Ways to secure your API• Basic Authentication.

• Token Based Authentication.

• OAuth 2.0 Protocol, Roles and Flows.

• Demo

Why we are building HTTP Services?• Enterprise wants to integrate with others, HTTP Services

is your way.

• (Mobile devices, Smart homes, Intelligent devices, IoT, etc...) all speaks HTTP.

• New trends of building modern web application (SPA, JS Frameworks).

Should I care about HTTP Service Security?• Definitely! Your Web API is publicly accessible.

• No Active Directory, no Windows Authentication.

• When designing your Web API, security is a first class citizen.

• Shall I build my own security model?

Sloppy HTTP Services and Apps• Case 1:• Hardcoding API Key in mobile applications, with fiddler proxy API

Key was exposed.

• Access checks are done on front-end. Backed-end server should never trust the UI.

Sloppy HTTP Services and Apps• Case 2:• Leaky API, returning hashed user passwords.

• People tend to reuse passwords!

HTTP Services is stateless!• HTTP Service is stateless, no sessions between the client

and the server.

• Authentication should be done with each request from front-end to the back-end server.

Ways to secure your API• 1 - Basic Authentication (Very simple)• Client needs to send Username/Password with each request –

Client will store credentials somewhere – Bad Idea?

• Your password is your master key, if it is compromised, your account is compromised.

• On the back-end server will validate credentials with each request, intentionally slow process, why?

• Should be used over SSL only.

• Try to avoid it as much as possible.

• Any alternatives?

GET /orders HTTP/1.1Host: api.example.com

Authorization: Basic dGFpc2VlcjpwYXNzd29yZA==

Ways to secure your API – Cont.• 2 – Token Based Authentication• How this happen?

1. Front-end presents username/password to (/token) end point.2. Back-end server validates credentials.3. Back-end server returns a magical string (Access Token)4. Front-end presents Access Token with each request in the

Authorization header using Bearer scheme.POST /token HTTP/1.1 Host: api.example.com grant_type=password &username=taiseer &password=password

{ "access_token": “YsSHs2rrsh8Vs8fggdsd44jssfVJ8h95sds", "token_type": "Bearer", "expires": 3600}

GET /orders HTTP/1.1Host: api.example.com

Authorization: Bearer YsSHs2rrsh8Vs8fggdsd44jssfVJ8h95sds

Ways to secure your API – Cont.• 2 – Token Based Authentication• What is Access Token?• Self contained data structure represented in string.• Contains information about user identity• Have lifetime and should expire• Should be signed, sometimes encrypted by the server.

• Access Tokens like Cash, so SSL everywhere!

• Access Token != Password (Token compromised, master key - password is safe)

Ways to secure your API – Cont.• 2 – Token Based Authentication – Cont.• Any drawbacks?• Self contained tokens are not revocable!• User changes password, access token still valid.

• Solution?• Issue short lived access tokens (15 minutes).• Refresh Access Tokens silently using Refresh Tokens.• Refresh Tokens are revocable, you are in good shape!• Adds complexity to the front-end and the back-end!

OAuth 2.0 Protocol• OAuth 2.0 is set of spec. and standards to build on top of

it.

• Different flows to protect HTTP services.

• Four main roles:

OAuth 2.0 Flows1. Resource owner password credentials flow• Should be used with trusted clients (mobile apps you trust)

2. Implicit flow• Good for 3rd party mobile apps.

• Client (mobile apps) never sees the password.

3. Authorization Code flow• Web server apps talking to each other.

4. Client Credentials flow• Machine to Machine (No human interaction).

Demo• Implementing the resource owner password credentials

flow

Thank You!