 Hello, everyone. This is Claudio Covino speaking again. In this third video in our series of four, I'm going to be showing the introspection flow implementation with ConConnect Enterprise and Octa Identity Provider. The ConConnect Enterprise control plane hosted as a service is used to create new APIs and policies and publish them to my data plane running as a Docker container in an AWS EC2 instance. The introspection flow is part of the token validation process. At the request processing time, Con Gateway evaluates the injected token to see if it's still valid to be passed to the obscene services. The evaluation hits a specific Octa endpoint passing the received token. Based on the response provided by Octa, Con Gateway accepts or rejects the request. For production environments, the OpenDConnect plugin provides caching capabilities for the Octa's responses. However, for the purpose of this demo, I'm going to disable caching to get a better view of the flow. In regard to Octa settings, I'm going to use the same client credentials application I had created before. However, my OpenDConnect plugin has to be set with specific parameters to implement introspection. So again, here's the ConConnect Enterprise Control Plane at Minguie showing the service in the service hub with the new introspection route with the same OpenDConnect plugin enabled. So let's check the plugin settings this time. There you go. Besides the regular issuer parameter, for the introspection flow, we should turn introspect JWT tokens on as well as the introspection endpoint with the specific endpoint provided by Octa to implement introspection. And now we're ready to see token introspection action. To get a better view of the flow, I'm going to use Insonia, which is Conx's API spec editor to send requests to both Octa and Connect. So here are my two requests. The first one I'm sending to Octa, and I'm accessing the expected parameters to get authenticated and receive a token. For the second one, to consume the route, I'm using a specific Insonia capability called request chaining. In this sense, I'll be able to extract values from the response of a given request to build new ones. In my case, I'm extracting the access token from the Octa's response to build the other request and then sending to connect. Okay. Now let's send the request to Octa to get our token. There it is. And then this time we can see that the Conx request is ready to be sent since we got the Octa's token injected inside of it. However, it's important to notice that Connect is validating the token behind the scenes. In fact, he is one EC2 terminal where my data plane is running and I'm grabbing the specific Docker container log. So as you can see, since I have disabled introspection caching for the OpenD Connect plugin, Connect hits Octa for each request sent to it to validate the token. Another way to see introspection is deactivating the Octa application. Doing so, all tokens related to it will be considered invalid and as a consequence will not be accepted by Conx again. So let's get back to Octa's application and deactivated it and then we should get some 401 error code from Conx. That concludes this Octa and Conx demo. Hope you have enjoyed it. See you in the last feed of the series.