HTTP Services & REST API Security
Download as PPTX, PDF•2 likes•3,114 views
The document discusses the importance of HTTP service security for integrating with modern enterprise applications and devices. It highlights common security flaws in API design, such as hardcoding credentials and leaky APIs, and outlines methods for securing APIs, including basic and token-based authentication, as well as the OAuth 2.0 protocol. The document also emphasizes the need for secure practices and the potential complexities introduced by different authentication mechanisms.
HTTP Services & REST API Security
- 1. HTTP Services Security Taiseer Joudeh Corporate IT Manager at Aramex @tjoudeh http://bitoftech.net
- 2. 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
- 3. 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).
- 4. 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?
- 5. 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.
- 6. Sloppy HTTP Services and Apps • Case 2: • Leaky API, returning hashed user passwords. • People tend to reuse passwords!
- 7. 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.
- 8. 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.1 Host: api.example.com Authorization: Basic dGFpc2VlcjpwYXNzd29yZA==
- 9. 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.1 Host: api.example.com Authorization: Bearer YsSHs2rrsh8Vs8fggdsd44jssfVJ8h95sds
- 10. 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)
- 11. 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!
- 12. 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:
- 13. OAuth 2.0 Flows 1. 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).
- 14. Demo • Implementing the resource owner password credentials flow
- 15. Thank You!