Advanced API Security

Part-I Getting StartedChapter 1: Managed APIs (20 pages)Enterprise API adoption has gone beyond predictions. It has become the 'coolest' way of exposing business functionalities to the outside world. Both your public and private APIs, need to be protected, monitored and managed. A simple API can be turned into a 'Managed API' by building QoS features on top of it. 1. The API Evolution2. API vs. Managed API3. API vs. Service4. Discovering and Describing APIs (WADL, Swagger)5. API Economy6. Microservices7. Overview of Salesforce, Amazon, Twitter and Facebook APIsChapter 2: Pragmatic REST (20 pages)1. Understanding REST2. REST design philosophy3. Richardson Maturity Model4. REST vs. Pragmatic REST5. RESTful API design practicesChapter 3: JSON (15 pages)1. JSON Basics2. XML vs. JSON3. JSON HTTP requestChapter 4: Secured by Design (20 pages)Security is not an afterthought. It has to be an integral part of any development project - so as for APIs. While designing an API to cater for business needs, we need to take into consideration the audience of the API and the expected level of security. Should it be private or publicly visible? Should it allow anonymous access or protected? How do we access control? How do we rate limit? How do we add protection for DoS attacks? How do we manage API keys? How do we secure messages in transit and at rest? How do we protect message for integrity and non-repudiation? Message level security vs. Transport level security?1. Design Challenges 2. Design Principles3. Confidentiality, Integrity, Availability (CIA)4. Security Controls5. Security Patterns6. Threat ModelingPart-II REST SecurityChapter 5: HTTP Basic / Digest Authentication (15 pages)HTTP Basic / Digest authentication can be used to secure APIs for authentication. This is mostly used when the client is also the resource owner or the owner of the API. HTTP Basic Authentication carries credentials over clear text, while Digest Authentication does not.1. HTTP Basic vs. Digest authentication2. LDAP/ Active Directory Integration 3. Securing APIs deployed in Tomcat with Basic / Digest Authentication4. Limitations5. Vulnerabilities, Threats and MitigationChapter 6: Mutual Authentication and Transport Level Security (20 pages)Confidentiality of the data passed on wire can be achieved either through message level security or through transport level security. TLS (SSL) is widely used for transport level security. It makes sure that the data on transit is secured for confidentiality, but as soon it leaves the wire, data will be in plain text. The popular form of TLS is - one-way SSL, where the server authenticates to the client and builds an encrypted channel for message passing. With Mutual Authentication, client is also expected to authenticate with X509 certificates.1. TLS2. TLS vs. SSL3. Mutual Authentication4. Securing APIs deployed in Tomcat with Mutual authentication5. Managing certificates6. POODLE attack7. Heartbleed Bug8. FREAK vulnerability in TLSPart-III OAuth Chapter 7: Identity Delegation (15 pages)Identity delegation plays a key role in enterprise security, when we have to deal with multiple parties. You may not be the direct consumer of the API - but a third party who wants to access on behalf of you. Sharing your credentials with a third party who wants to access a resource you own, on behalf of you, is an anti-pattern. Most of the web based applications / APIs developed prior to 2006 utilized credential sharing to facilitate identity delegation. Around 2006, many vendors started developing their own proprietary ways to address this concern without credential sharing.1. Google AuthSub2. Google Client Login3. Yahoo BBAuth4. FlickrAuth5. WRAPChapter 8: OAuth 1.0 (15 pages)OAuth 1.0 is the first ever standard to address the identity delegation concern without credential sharing. Since many proprietary standards started to creep in to solve the same problem, community got together and started building a widely accepted standard - so everyone can interoperate.1. OAuth 1.0 flow2. 3-legged OAuth vs. 2-legged OAuth3. Talking to Twitter APIs protected with OAuth 1.04. Limitations5. Vulnerabilities, Threats and MitigationChapter 9: OAuth 2.0 (40 pages)OAuth 2.0 provides an authorization framework for securing HTTP services with delegated access. OAuth 1.0 is coupled with signature-based security. Although it has provisions to use different signature algorithms, still it's signature based. One of the key criticisms against OAuth 1.0 is the burden enforced on OAuth clients for signature calculation and validation. This is not a completely valid argument. This is where we need proper tools to the rescue. Why an application developer needs to worry about signature handling? Delegate that to a third party library and stay calm. If you think OAuth 2.0 is better than OAuth 1.0 because of the simplicity added through OAuth 2.0 Bearer Token profile (against the signature based tokens in 1.0) - you've been misguided.The biggest advantage of OAuth 2.0 is its extensibility. The core OAuth 2.0 specification is not tightly coupled with a token type. There are several OAuth profiles being discussed under IETF OAuth working group at the moment. The Bearer token profile is already a proposed IETF standard - RFC 67501. OAuth 2.0 flow2. Grant types3. Bearer Token Profile4. Authentication vs. Authorization5. Securing APIs with OAuth 2.06. Best Practices7. Talking to Salesforce APIs secured with OAuth 2.08. Talking to Facebook APIs secured with OAuth 2.09. Limitations10) Vulnerabilities, Threats and MitigationChapter 10: Cross Origin Resource Sharing (15 pages)1. Same Origin Policy2. Cross origin techniques3. Introducing CORS4. CORS request/response flow5. CORS and APIsPart-IV OAuth 2.0 ProfilesChapter 11: MAC Token Profile (10 pages)The MAC Token Profile is very much closer to what we have in OAuth 1.0. OAuth authorization server will issue a MAC key along with the signature algorithm to be used and an access token that can be used as an identifier for the MAC key. Once the client has access to the MAC key, it can use it to sign a normalized string derived from the request to the resource server. Unlike in Bearer token, the MAC key will never be shared between the client and the resource server. It's only known to the authorization server and the client. Once the resource server gets the signed message with MAC headers, it has to validate the signature by talking to the authorization server. Under the MAC token profile, TLS is only needed for the first step, during the initial handshake where the client gets the MAC key from the authorization server. Calls to the resource server need not to be on TLS, as we never expose MAC key over the wire.1. OAuth 2.0 flow2. Bearer Token Profile vs. MAC token profile3. Limitations4. Vulnerabilities, Threats and MitigationChapter 12: Token Introspection (10 pages)OAuth 2.0 does not define a standard API to communicate between OAuth Resource Server and the Authorization Server. This made to creep in proprietary APIs, hence, makes Resource Server coupled to the Authorization Server. Token Introspection profile for OAuth fills this gap by proposing a standard API to be exposed by the Authorization Server, where Resource Server can talk to and retrieve token metadata. Chapter 13: Token Revocation (10 pages)Token Revocation is a need due to many reasons. Trust between the resource owner and the client might be broken, hence, the resource owner needs to revoke access from the client. Similarly, the client can also initiate token revocation, in case it loses OAuth keys.Chapter 14: User Managed Access (20 pages)User-Managed Access (UMA) Profile of OAuth 2.0 introduces a standard endpoint to share metadata at the authorization server level. The authorization server can publish its token endpoint, supported token types and supported grant types via this UMA authorization server configuration data endpoint as a JSON document. With UMA, OAuth 2.0 Authorization Server has two interfaces. One between the Authorization Server and the Client and the other one between the Authorization Server and the Resource Server.1. ProtectServe2. UMA architecture3. UMA phases4. UMA APIs5. Securing APIs in a distributed setup.Chapter 15: SAML 2.0 Bearer Assertion Profile (10 pages)Customers and partners can access public APIs, where we do not maintain credentials internally. In that case we cannot directly authenticate them. So, we have to have a federated authentication setup for APIs, where we would trust a given partner domain, but not individuals. The SAML 2.0 Bearer Assertion Profile for OAuth 2.0 addresses this concern.The SAML 2.0 Bearer Assertion Profile, which is built on top of OAuth 2.0 Assertion Profile, defines the use of a SAML 2.0 Bearer Assertion as a way of requesting an OAuth 2.0 access token as well as a way of authenticating the client. Chapter 16: JSON Web Token (JWT) Profile for OAuth 2.0 (10 pages)JSON Web Token (JWT) Profile for OAuth 2.0 specification defines the use of a JSON Web Token (JWT) Bearer Token as a means for requesting an OAuth 2.0 access token as well as for use as a means of client authentication.Chapter 17: OpenID Connect (30 pages)OpenID Connect is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.1. OpenID Connect Basic Profile2. Discovery3. WebFinger4. Dynamic Registration5. Session ManagementPart-V JSON SecurityChapter 18: Basic Cryptography (20 pages)1. Secret key cryptography2. Public key cryptography3. X509 certificates4. Hashing functions5. Signature schemesChapter 19: JSON Web Encryption (15 pages)JSON Web Encryption is a standard developed by IETF JOSE working group to standardize the process of encrypting JSON payloads.Chapter 20: JSON Web Signature (15 pages)JSON Web Signature is standard developed by IETF JOSE working group to standardize the process of signing JSON payloads.Part-VI Other TopicsChapter 21: Access Controlling with XACML (15 pages)Chapter 22: IoT Security (20 pages)Chapter 23: Patterns & Practices (20 pages)