 Hello everyone, this is Claudio Covilli speaking. This is the second video in a series of four showing the integration of ConConnect Enterprise with Octa IdentiProvider, implementing some OpenD Connect based authentication and authorization use cases. For this second video, I'm going to demo the authorization code flow applied to user authentication processes in the same environment I used before. And here's the ConConnect and Octa integration topology again. The ConConnect Enterprise control plane, hosted as a service, used to create new APIs and policies and published then to my data plane running as a Docker container in an AWS EC2 instance. In summary, the authorization code flow goes through these steps. First of all, the user tries to consume the API. However, since the request doesn't have any token injected, Con redirects the user to the IdentiProvider, in our case, Octa. After the user authenticates on Octa, the provider sends user back to Con with an authorization code. Con validates the parameters and then goes on with exchanging the authorization code with the tokens by calling the Octa's token endpoint. Here's the ConConnect Enterprise control plane enemy GUI showing the service I have created before in the Cesshub. The service has two routes already defined. The first one we use to show the client credentials flow. Today, we're going to use the second one to apply the same OpenDConnect plugin, this time implementing the authorization code flow. In relation to Octa's settings, I have already prepared an application to implement the flow. So here's the con authorization code application and I'd like to highlight some of those settings. Besides the client ID and client secret we're going to use to configure the OpenDConnect plugin, the Octa app has the authorization code option turned on as well as the signing redirect URI set with the route available in my data plane. That means the authorization code is accepted for this URI only. In fact, we're free to consume the route now since we don't have any policy applied controlling it. And now just like we did for the client credentials flow, let's go back to connect control plane to apply the OpenDConnect plugin and then implement the authorization code flow. So the first parameter we need to set to our OpenDConnect plugin is the client ID. The second is the client secret and the last one is the Octa's issuer endpoint. We are good to create to enable the OpenDConnect plugin to our route. And then if you try to consume the route again, since authorization code is used for user authentication, we're going to get redirected to Octa's user interface to present our credentials. Once we have presented our correct credentials, we're going to get authenticated by Octa and redirected back to the API gateway. And this time we'll be able to consume the API because we got the identity token ejected inside our request. As a matter of fact, here's the identity token Octa has issued for us. And then if you go to jwt.io website, we can check the token. That concludes my second Kong and Octa demo. See you in the next one. Thanks a lot. One more time.