This book will prepare you to meet the next wave of challenges in enterprise security, guiding you through and sharing best practices for designing APIs for rock-solid security. It will explore different security standards and protocols, helping you choose the right option for your needs. Advanced API Security, Second Edition explains in depth how to secure APIs from traditional HTTP Basic Authentication to OAuth 2.0 and the standards built around it. Keep your business thriving while keeping enemies away. Build APIs with rock-solid security. The book takes you through the best practices in designing APIs for rock-solid security, provides an in depth understanding of most widely adopted security standards for API security and teaches you how to compare and contrast different security standards/protocols to find out what suits your business needs, the best.
This new edition enhances all the topics discussed in its predecessor with the latest up to date information, and provides more focus on beginners to REST, JSON, Microservices and API security. Additionally, it covers how to secure APIs for the Internet of Things (IoT).
The Advanced API Security 2nd Edition is for Enterprise Security Architects and Developers who are designing, building and managing APIs. The book will provide guidelines, best practices in designing APIs and threat mitigation techniques for Enterprise Security Architects while developers would be able to gain hands-on experience by developing API clients against Facebook, Twitter, Salesforce and many other cloud service providers.
What you’ll learn
• Build APIs with rock-solid security by understanding best practices and design guidelines.
• Compare and contrast different security standards/protocols to find out what suits your busine
ss needs, the best.• Expand business APIs to partners and outsiders with Identity Federation.
• Get hands-on experience in developing clients against Facebook, Twitter, and Salesforce APIs.
• Understand and learn how to secure Internet of Things.
Part-I Getting Started
Chapter 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 Evolution
2. API vs. Managed API
3. API vs. Service
4. Discovering and Describing APIs (WADL, Swagger)
7. Overview of Salesforce, Amazon, Twitter and Facebook APIs
Chapter 2: Pragmatic REST (20 pages)
1. Understanding REST
2. REST design philosophy
3. Richardson Maturity Model
4. REST vs. Pragmatic REST
5. RESTful API design practices
Chapter 3: JSON (15 pages)
JSON Basics2. XML vs. JSON
3. JSON HTTP request
Chapter 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?
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 authentication
2. LDAP/ Active Directory Integration
3. Securing APIs deployed in Tomcat with Basic / Digest Authentication
5. Vulnerabilities, Threats and Mitigation
Chapter 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 wir
e, 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.
2. TLS vs. SSL
3. Mutual Authentication
4. Securing APIs deployed in Tomcat with Mutual authentication
5. Managing certificates
6. POODLE attack
7. Heartbleed Bug
8. FREAK vulnerability in TLS
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 AuthSub
2. Google Client Login
3. Yahoo BBAuth
Chapter 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 flow
2. 3-legged OAuth vs. 2-legged OAuth
3. Talking to Twitter APIs protected with OAuth 1.0
5. Vulnerabilities, Threats and Mitigation
Chapter 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 6750
1. OAuth 2.0 flow
2. Grant types
3. Bearer Token Profile
4. Authentication vs. Authorization
5. Securing APIs with OAuth 2.0
6. Best Practices
7. Talking to Salesforce APIs secured with OAuth 2.0
8. Talking to Facebook APIs secured with OAuth 2.0
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 flow
2. Bearer Token Profile vs. MAC token profile
4. Vulnerabilities, Threats and Mitigation
Chapter 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 Introspecti
on 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 author
ization 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.
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 identit
y 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 Profile
4. Dynamic Registration
5. Session Management
Part-V JSON Security
Chapter 18: Basic Cryptography (20 pages)
1. Secret key cryptography
2. Public key cryptography
3. X509 certificates
4. Hashing functions
5. Signature schemes
Chapter 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 Topics
Chapter 21: Access Controlling with XACML (15 pages)
Chapter 22: IoT Security (20 pages)
Chapter 23: Patterns & Practices (20 pages)
Prabath Siriwardena is an identity evangelist, author, blogger, and the VP of Identity Management and Security at WSO2. He has more than 11 years of industry experience in designing and building critical Identity and Access Management (IAM) infrastructure for global enterprises, including many Fortune 100/500 companies. As a technology evangelist, Prabath has published five books. He blogs on various topics from blockchain, PSD2, GDPR, IAM to microservices security. He also runs a YouTube channel. Prabath has spoken at many conferences including, RSAConference, Identiverse, European Identity Conference, Consumer Identity World USA, API World, API Strategy & Practice Con, QCon, OSCON, and WSO2Con. He has travelled the world conducting workshops/meetups to evangelize IAM communities. He is the founder of the Silicon Valley IAM User Group, the largest IAM meetup in the San Francisco Bay Area.
Explains how to build APIs with rock-solid security by understanding best practices and design guidelines
Leaves readers with a great insight on API security related standards and protocols out there, like OAuth, OpenID Connect, SAML, JWE, JWS, UMA, XACML, WebFinger Provides an overview of securing Internet of Things, explaining how to and the associated challenges
En continuant à naviguer, vous autorisez Lavoisier à déposer des cookies à des fins de mesure d'audience.
Pour en savoir plus et paramétrer les cookies, rendez-vous sur la page
Confidentialité & Sécurité.