Advanced API Security Quotes

“We treat a native mobile application as an untrusted or a public client. A client application, which is not capable of protecting its own keys or credentials, is identified as a public client under OAuth terminology.”
― Prabath Siriwardena, Advanced API Security: OAuth 2.0 and Beyond

“OpenID provider doesn’t ask for credentials but uses the authenticated session you created before at the OpenID provider. This authenticated session is maintained either by a cookie until the browser is closed or with persistent cookies.”
― Prabath Siriwardena, Advanced API Security: OAuth 2.0 and Beyond

“OpenID and OAuth 1.0 address two different concerns. OpenID is about authentication, whereas OAuth 1.0 is about delegated authorization.”
― Prabath Siriwardena, Advanced API Security: OAuth 2.0 and Beyond

“Ninety-two percent of the 8 billion+ authentication requests Microsoft Azure AD handled in May 2018 were from OpenID Connect–enabled applications.”
― Prabath Siriwardena, Advanced API Security: OAuth 2.0 and Beyond

“The API gateway is the most common pattern in securing APIs in a production deployment. In other words, it’s the entry point to your API deployment. There are many open source and proprietary products out there, which implement the API gateway pattern, which we commonly identify as API gateways. An API gateway is a policy enforcement point (PEP), which centrally enforces authentication, authorization, and throttling policies. Further we can use an API gateway to centrally gather all the analytics related to APIs and publish those to an analytics product for further analysis and presentation.”
― Prabath Siriwardena, Advanced API Security: OAuth 2.0 and Beyond

“The OAuth 2.0 specification is built around three types of client profiles: web applications, user agent–based applications, and native applications. Web applications are considered to be confidential clients, running on a web server: end users or resource owners access such applications via a web browser. User agent–based applications are considered to be public clients: they download the code from a web server and run it on the user agent, such as JavaScript running in the browser. These clients are incapable of protecting their credentials—the end user can see anything in the JavaScript. Native applications are also considered as public clients: these clients are under the control of the end user, and any confidential data stored in those applications can be extracted out. Android and iOS native applications are a couple of examples.”
― Prabath Siriwardena, Advanced API Security: OAuth 2.0 and Beyond

“the application wants to access the API just being itself, then we should use client credentials grant type and, if not, should use authorization code grant type. Both the implicit and password grant types are now obsolete.”
― Prabath Siriwardena, Advanced API Security: OAuth 2.0 and Beyond

“NoteEach refresh token has its own lifetime. Compared to the lifetime of the access token, the refresh token’s is longer: the lifetime of an access token is in minutes, whereas the lifetime of a refresh token is in days.”
― Prabath Siriwardena, Advanced API Security: OAuth 2.0 and Beyond

“NoteThe ultimate goal of any OAuth 2.0 grant type is to provide a token (which is known as access token) to the client application. The client application can use this token to access a resource. An access token is bound to the resource owner, client application, and one or more scopes. Given an access token, the authorization server knows who the corresponding resource owner and client application and also what the attached scopes are.”
― Prabath Siriwardena, Advanced API Security: OAuth 2.0 and Beyond

“Also you can interpret scope as a permission, or in other words, scope defines what actions the client application can do on a given resource”
― Prabath Siriwardena, Advanced API Security: OAuth 2.0 and Beyond

“Once the application data transmission between the client and the server begins, the other should acknowledge each data packet sent by either party. As a response to the first TCP packet sent by the client, which carries application data, the server will respond with a TCP ACK packet,”
― Prabath Siriwardena, Advanced API Security: OAuth 2.0 and Beyond

“The HTTP, which operates at the application layer, takes care of building the HTTP message with all relevant headers and passes it to the TCP at the transport layer. Whatever the data it receives from the application layer, the TCP encapsulates with its own headers and passes it through the rest of the layers in the TCP/IP stack.”
― Prabath Siriwardena, Advanced API Security: OAuth 2.0 and Beyond

“The Ethernet protocol operates at the network access layer.”
― Prabath Siriwardena, Advanced API Security: OAuth 2.0 and Beyond

“The Internet Protocol (IP) functions at the Internet layer. Its responsibility is to provide a hardware-independent addressing scheme to the messages pass-through. Finally, it becomes the responsibility of the network access layer to transport the messages via the physical network.”
― Prabath Siriwardena, Advanced API Security: OAuth 2.0 and Beyond

“Hypertext Transfer Protocol (HTTP) is an application layer protocol, which is transport layer protocol agnostic.”
― Prabath Siriwardena, Advanced API Security: OAuth 2.0 and Beyond

“In achieving CIA, authentication, authorization, nonrepudiation, and auditing are four prominent controls, which play a vital role.”
― Prabath Siriwardena, Advanced API Security: OAuth 2.0 and Beyond

“Confidentiality attribute of the CIA triad worries about how to protect data from unintended recipients, both at rest and in transit.”
― Prabath Siriwardena, Advanced API Security: OAuth 2.0 and Beyond

“Confidentiality, integrity, and availability (CIA), widely known as the triad of information security, are three key factors used in benchmarking information systems security.”
― Prabath Siriwardena, Advanced API Security: OAuth 2.0 and Beyond

“Gary McGraw in his book, Software Security, highlights complexity in both the code and the system design as one attribute that is responsible for the high rate of data breaches.”
― Prabath Siriwardena, Advanced API Security: OAuth 2.0 and Beyond

“The principle of least privilege states that an entity should only have the required set of permissions to perform the actions for which they are authorized, and no more.”
― Prabath Siriwardena, Advanced API Security: OAuth 2.0 and Beyond

“The most challenging thing in any security design is to find and maintain the right balance between security and the user comfort.”
― Prabath Siriwardena, Advanced API Security: OAuth 2.0 and Beyond

“Connectivity, extensibility, and complexity are the three trends behind the rise of data breaches around the globe in the last few years.”
― Prabath Siriwardena, Advanced API Security: OAuth 2.0 and Beyond

“The most worrisome fact is that, according to an article5 by The Economist magazine, the average time between an attacker breaching a network and its owner noticing the intrusion is 205 days.”
― Prabath Siriwardena, Advanced API Security: OAuth 2.0 and Beyond

“Microservices have not substituted APIs—rather they work together.”
― Prabath Siriwardena, Advanced API Security: OAuth 2.0 and Beyond

“With the microservices design, where each distinguished functional component is developed into a microservice, based on their business capabilities, will have its own database—so each such service can scale end to end without having any dependency on other microservices.”
― Prabath Siriwardena, Advanced API Security: OAuth 2.0 and Beyond

“With the microservices-based architecture, each service is designed with its own autonomy and highly decoupled from each other. The team behind each microservice can follow their own standards, tools, and protocols. This makes a decentralized governance model more meaningful for microservices architecture.”
― Prabath Siriwardena, Advanced API Security: OAuth 2.0 and Beyond

“Smart endpoints and dumb pipes: Each microservice is developed for a well-defined scope. Once again, the best example is Netflix.42 Netflix started with a single monolithic web application called netflix.war in 2008, and later in 2012, as a solution to address vertical scalability concerns, they moved into a microservices-based approach, where they have hundreds of fine-grained microservices today. The challenge here is how microservices talk to each other. Since the scope of each microservice is small (or micro), to accomplish a given business requirement, microservices have to talk to each other. Each microservice would be a smart endpoint, which exactly knows how to process an incoming request and generate the response.”
― Prabath Siriwardena, Advanced API Security: OAuth 2.0 and Beyond

“Products not projects:”
― Prabath Siriwardena, Advanced API Security: OAuth 2.0 and Beyond

“Organized around business capabilities:”
― Prabath Siriwardena, Advanced API Security: OAuth 2.0 and Beyond

“Componentization via services: In microservices, the primary way of componentizing will be via services. This is a bit different from the traditional componentizing via libraries. A library in the Java world is a jar file, and in .NET world, it’s a DLL file.”
― Prabath Siriwardena, Advanced API Security: OAuth 2.0 and Beyond