messages on social media. At the beginning of the flow, the application would send you to a  Facebook authorization page. To get to that screen on Facebook, you must log in to  Facebook itself (authentication). Facebook then can present a page to you where you agree  to let the application post on your behalf (authorization). You are then directed back to the  application, which now has the specific authorization to post only messages and nothing.  Furthermore, it had not sight of your username/password on Facebook at any time during the  flow.  For simplicity, we have skipped over some of the subtlety of the flow, to focus on the key  points as seen from the user’s perspective. Behind the scenes, there are many important  details such as how Facebook confirms the identity of the application, safe authorization  token retrieval, token expiry, token encryption, and so on. OAuth is a sophisticated protocol  as are all the related standards; complex to learn and easy to implement insecurely. API  management products aim to simplify these challenges as much as possible, enabling the  setup of OAuth flows through guided configuration. For an example, see 6.5.3, “Securing the  API” on page 264. Tokens The OAuth protocol does not specify the format of the tokens that are used to hold  authorization information.  A common choice is the JSON Web Token (JWT). Ultimately a JWT is just a convenient way  for transferring a token of data and it is used in many different security-related use cases.  They can be digitally signed to ensure its integrity, and they are self-describing/self-contained One of the key benefits of tokens such as JWT is that they are self-signed. As a result, they  can be validated without having to go back to the originator, thus reducing the number of  network interactions needed. This becomes particularly important in cloud-native applications  where there are many more fine-grained components that each need to validate the tokens  that they receive.  However, one of the downsides of the self-contained token is that it is harder to revoke. After  it is out in the wild, its self-validating nature makes it appear legitimate even if it is not. So, it is  susceptible to man-in-the-middle attacks. Of course, the best defense against this is to  reduce the self-contained time so that it expires in as quickly as possible (based on the use  case). In other words, minimize the attack-opportunity window.  IBM API Connect provides combined OAuth and JWT capabilities which are discussed in  detail in 6.5.3, “Securing the API” on page 264. 4.9.5 Hybrid solutions: Securing cloud to cloud and cloud to ground In this final subsection, we consider how cloud-native applications should connect to other  applications beyond its boundary.  The first consideration is how we enable a network path between our cloud-native  applications that are spread to other clouds, or to our existing system of record on-premises  (on the ground).  For illustration, consider the following deployment landscape where we have applications that  are spread across three network zones: On-premise, IBM Cloud, and Google Cloud.  Chapter 4. Cloud-native concepts and technology  135