Mes highlights
JSON Web Encryption (JWE) and JSON Web Signature (JWS) are two increasingly popular standards for securing JSON messages.
REST (JSON over HTTP).
naked API is an unmanaged API. An unmanaged API has its own deficiencies
A comprehensive API management platform needs to have at least three main components: a publisher, a store, and a gateway (see Figure 1-9)
The API publisher provides tooling support to create and publish API
A store goes beyond just listing APIs (which is what ProgrammableWeb does): it lets API consumers or application developers subscribe to APIs, and it manages API subscriptions
The gateway checks all the requests that pass through it against authentication, authorization, and throttling policies
Most API stores make discovery via searching and tagging.
Swagger specification is promising to be the most widely used format for describing APIs
APIs are known to be public facing, while microservices are used internally
one API could talk to multiple microservices to cater a request generated by one of the devices supported by Netflix. Microservices have not substituted APIs—rather they work together.
An API store (or a developer portal), API publisher, and API gateway are the three key ingredients in building an API management solution
The most challenging thing in any security design is to find and maintain the right balance between security and the user comfort.
Doing encryption/decryption process at the dedicated hardware level is far more cost-effective than doing the same at the application level, in terms of performance.
Using message-level protection is much costlier than simply using TLS
TLS bridging or with TLS tunneling
Message-level encryption happens at the application layer, and it has to take into consideration the type and the structure of the message to carry out the encryption process
eight types of DoS attacks that can be carried out against SOAP- based APIs with XML payloads:
For example, to prevent a coercive parsing attack, the XML parser can enforce a limit on the number of elements. Similarly, if your application executes a thread for a longer time, you can set a threshold and kill it
A proper security design should care about all the communication links in the system
Securing APIs with Transport Layer Security (TLS) is the most common form of protection we see in any API deployment
API implemented in Java Spring Boot
server.ssl.client-auth:need
configure Order API to trust the public key.
difference between OAuth 1.0 and 2.0 is that OAuth 1.0 is a standard protocol for identity delegation, whereas OAuth 2.0 is a highly extensible authorization framework.
OAuth 2.0 introduces four actors in a typical OAuth flow. The following explains the role of each of them with respect to Figure 4-1:
grant type defines a well-defined process to get the consent from the resource owner to access a resource on his/her behalf for a well-defined purpose. In OAuth 2.0, this well-defined purpose is also called scope
interpret scope as a permission, or in other words, scope defines what actions the client application can do on a given resource
The value of response_type parameter must be code. This indicates to the authorization server that the request is for an authorization code (under the authorization code grant type).
In most of the cases, the token endpoint is secured with HTTP Basic authentication, but it is not a must. For stronger security, one may use mutual TLS as well, and if you are using the authorization code grant type from a single-page app or a mobile app, then you may not use any credentials at all. The following shows a sample request (step 6) to the token endpoint.
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.
implicit grant type to acquire an access token is mostly used by JavaScript clients running in the web browser (see Figure 4-3). Even for JavaScript clients now, we do not recommend using implicit grant type, rather use authorization code grant type with no client authentication
The implicit grant type sends the access token as a URI fragment and doesn’t provide any refreshing mechanism
web server of the client application will return back an HTML page with a JavaScript, which knows how to extract the access_token from the URI fragment, which still remains in the browser address bar. In general this is how single-page applications work.
the resource owner password credentials grant type was introduced to aid migration from http Basic authentication and digest authentication to Oauth 2.0.
This client credential grant type is mostly used for system-to-system interactions with no end user
the authorization server also has the option to return a new refresh token each time the client refreshes the access token.
If 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
OAuth 2.0 has two main token profiles: OAuth 2.0 Bearer Token Profile and OAuth 2.0 MAC Token Profile
an Oauth 2.0 bearer token can be a reference token or self-contained token.
a self-contained access token is a JsOn Web token (JWt)
When the resource server gets an access token, which is a reference token, then to validate the token, it has to talk to the authorization server (or the token issuer). When the access token is a JWt, the resource server can validate the token by itself, by verifying the signature of the JWt.
send the authorization request to the OAuth authorization server in two ways. One way is called passing by value, and the other is passing by reference.
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.
The responsibility of the security token service (STS) is to issue tokens to its clients and respond to the validation requests from the API gateway
OpenID Connect is the most popular Identity Federation protocol
The basic principle behind both OpenID and SAML (discussed in Chapter 12) is the same. Both can be used to facilitate web single sign-on (SSO) and cross- domain identity federation. OpenID is more community-friendly, user centric, and decentralized
OpenID solves the problem of scattered profiles on different websites. With OpenID, you maintain your profile only at your OpenID provider, and all the other sites become OpenID relying parties
An OAuth 2.0 authorization server that supports OpenID Connect returns an ID token along with the access token.
OAuth talks about access delegation, while OpenID Connect talks about authentication
In fact OpenID Connect, independent of OAuth 2.0 grant types, defined a set of flows: code flow, implicit flow, and hybrid flow
The first element of the JWT is called the JavaScript Object Signing and Encryption (JOSE) header
The second element of the JWT is known as either the JWT payload or the JWT claims set
Canonicalization is the process of converting different forms of a message into a single standard form.