 I want to welcome Claudio who we have here joining us from Kong and he'll be walking through this lab and you'll be able to follow along and also ask questions throughout the session. So do make sure you join the chat room and I guess without further ado, we will bring him on and go ahead and kick things off. So welcome Claudio and thanks for joining. Thank you so very much Aaron. Yeah again, my name is Claudio Convivum. I'm a solution architect here at Kong. As a matter of fact, I've been working here at Kong for almost three years now. I'm a member of the license team, responsible for you know very, partnerships and license, like for instance Octa is one of the most important ones I've been working with. That's it's a pleasure talking to you guys. So for today I have prepared a workshop of course exploring these Kong Connecting to Price and Octa integration points. As a matter of fact, we're going to explore for them the most I would say the four most common use cases when we come to these integration Kong Connecting to Price and Octa. Before going through the use cases, I like to I put together some slides and then I like to go through them in order to show you how the topology looks like. The typical topology looks like with the API gate in Octa identity provider. So it's a very basic topology where we have the Kong Connecting to Price API gate in Octa working together of course but then you can as you can see the API gate that has been split up in two sub layers. Up here we got the control plane, the control plane responsible for the admin tasks. So every time you need to create a new API to define a policy change a policy existing policy you go you as an admin you go to the control plane and then do your job and then the control plane responsible for publishing the APIs and policies across the multiple data planes that I have in or the client. So for instance in these simple diagram you can see I got two data planes running the first one running my local machine and the second one you can have a the second data plane running as an EC2 instance in data blast for instance. So again every time I create a new API these APIs are going to be published in these two data planes and then the consumers will be able to send requests to the data plane and then go to the API and then in the upstream you might have behind it. You know your microservices, your services and so on and so forth. The topology is pretty straightforward but then again you know securely is one of the I would say the most important policy you should enable to your APIs and then in these sense you're going to have these slightly loosely coupled integration with octa and provider to implement open to connect based authentication processes. As a matter of fact both products Kong and octa implement you know fully implement the open to connect senders all the grants as a matter of fact the four of them client credentials authorization code password implicit I'm going to show you the two main ones as a matter of fact you know the document I'm going to share with you guys in a moment I'm going to describe how to implement two the two main ones client credentials in authorization code of course using octa as the data provider that's it so before we get started just to show you my daily environment here I hope was able to to register to Kong connect cloud and then the control plane instance for you so here's my I can log out and start it over so then you should go to connect.com HQ.com I'm going to see this login page and then just a minute you use your credentials and then you're going to get you're going to see your control plane so the control plane there's nothing here the control plane is running on cloud not cloud it's a trial control plane 30 day control plane the same thing applies to octa control plane so again let me log out and then starting over so I have registered myself first and then use my my oops again for octa octas control too many passwords now I think I got it so both control planes are there again connect API gateway and octa and then here's the document I think Aero has shared the link with you guys the document I put together again I'm going through the document in a moment but then again just the summary of the document the structure of the document for you guys so kind of you know again we've got these executive summary first of all like you know describing the the integration the con connect enterprise API gateway and octa I can again the same topology here and then the document describes how first of all how to define an API using connect control plane and then later on we're going to explore four as I said four use cases the first the first two ones we're going to explore uh two okay any connect grants the client potential grants very very important if you're implementing the application authentication process and the second one the authorization code if we're going to implement user authentication process in perspective that's the third use case very very important to have these token validation at the API request processing time so every time the API gateway receives the API request the API gateway will be responsible for connecting to octa I didn't provide it to make sure the token issued by octa previously is still valid it's still valid so it's not just a matter to validate the JWT signature and check the claims inside of it but but most importantly to to make sure octa is still considered the the token is a valid one and the last use case I'm going you're going to implement a access control that happens after the authentication uh related to authorization of course and then I'm going to use octa's uh group and claims uh notions to implement these access control policy very very basic like you know for instance you're going to present your JWT but because you don't belong to a specific octa group you won't be able to consume the API so that's it four use cases um the two first one for authentication the third for token validation and the fourth for authorization access control if you will so I'm going through um I'm going to show you how to uh first of all what I got only the two the the two control planes con control plane and octa control plane so I'm going to show you how to instantiate the very first data plane in order to to send requests to the API and then consume the API so again he's the the the first chapter of the document so very very important oh there's another comment over here very very important I have described how to do how to create data planes and um API is using both CLI and the connect CLI and connect GUI so exactly the same process you can see exactly the same process being described using CLI our CLI or our GUI exactly the same thing how to create an API using CLI and how to create exactly the same API using the GUI so but first of all I don't have any data plane let's create our data plane so if you go to the um your your terminal and run this comment over here you're gonna get a connect session I'm using of course I'm using exactly the same credentials I use for the control plane is my password and that's my trial control plane so that's okay to share my password with you guys so then again if I run this comment over here using my terminal I'm gonna get this connect session so this cookie over here is very very important so if you're going to use CLIs to do your job to create APIs to define policies okay and connect policies and so on so forth these cookies over here is very very important that's the cookie you use to refer to your session previously created by the control plane again I just got these the session over here I'm gonna copy this command the whole thing just make sure I got the cookie for me so again this cookie is important I'm gonna highlight this like this because I'm gonna use it later on and then just to make sure my control plane is all right that will be nice to run this comment over here just to get my control plane settings so again as I said before we're gonna use the cookie we got when we open our session so let's copy this cookie over here injecting my command and run the command send the request to the control plane and then the control plane is going to tell me the main control plane settings so the most important information we got of here is the ID that's the control plane ID so every every time you want to refer it to your control plane you should use this ID over here so kind of you know these output this here is just saying like you know the your control plane is a trial one he is the is a couldable uri the telemetric endpoint and so on so forth so kind of you know settings that you can use along the way while interacting with your control plane then again the most important one that's the ID over here so let me copy this again just make sure I got everything I need more precisely the my control plane ID so again let me copy this and save the ID up here highlighting it again just make sure I got the the right control plane ID and now just we just you know ransom you know send some request just make sure the control plane the control plane is it's up and running everything is fine now now it's it's time to create a very first data plane so if you go to the the control plane you're gonna see this runtime option up here so now you can see all my data planes instances I got this time I have instantiated three data planes so far you're gonna instantiate the four of instance if we click on this configure runtime you're gonna see these unix script over here before we copy it and running it I like to to to say that you know the the docker based runtime just a one flavor or the data plane you might have so as you can see over here you can instantiate other runtimes other data planes if you will for regular Linux operating system or even for Kubernetes so as you can see right now we provide support for three kinds of data planes again docker linux and kubernetes so here's the uh you know the specific settings for if you want to run your data plane in a kubernetes cluster all these data planes of course again they will be connected to my control plane so to make my life easier just for these demo for work workshop we're going to instantiate the the simplest one the docker based runtime the docker based data plane so I'm gonna copy this command over here I'm gonna save it because I'm gonna run it later on then again I'm gonna use my I'm gonna change this field over here with my control plane admin password before we run it just wanted to show you my doc my local docker environment his port container I got docker desktop installed in my mac os this is a I just got the port pain in here nothing more than that no containers no images no volumes no nothing and then I'm going to run the script we copied before so the script is going to the control plane not just to authenticate it to for authentication but actually to pull the docker image look and then install the image and instantiating the container for us you should be okay if you go back to portainer one more time you should see a brand new container up and running now and as you can see the container is based on this image over here which is the data plane in instant image you're using the images over here more than that as you can see the default ports we use for the data plane are the 40,000 so if you go to 40,000 local host if you will be 50p local host 40,000 you're gonna hit the data plane the local data plane running your local laptop so again the control plane is running our cloud the data plane is running your local laptop the message is here saying that you know no round matches with those values because you know we don't have any api defined in the in the control plane that's why we're receiving this this message over here so let's go to the control plane now to create a new way our very first api so we go to service over here again there's nothing in here we're going we're getting started and then first of all we need to create a new service let's call it service one just the name could be anything and then the service is going to have a version let's call it version one that's it and then the versions here you can have multiple versions for the same service if you will and then we click on the version one we just created there's a new implementation button over here we click on it that's the most important settings for the service as a matter of fact a con service consider a con service a an abstraction for an endpoint your upstream is exposing right now so again these URL here could be an endpoint exposed by you know a java application server could be a legacy system could be a kubernetes cluster could be a load balancer whatever in theory any upstream you might have more environment here for these workshop purpose i'm going to use the public htpbin.org service not sure if you guys know the service kind of you know it's just a echoing echo service if you hit it directly you're gonna see this page over here and then you can send any request like you know again is that echo service is a public echo service and then you know just pretending these echo services my upstream just using it to create my my service over here you can define your service or implementation you know not just with the url but you know the number of retries the api gateway the data plane will try to to connect to these upstream before considering not available the connection timeout the writing timeout client certificates if the connection requires a mutual tls tunnel that will be the case to include your client certificates of course the data plane will will play the client rule in the mutual tls tunnel and so on and then that's it the the second port of your api definition is where you define the public port of your api so define the path so the service we're going to expose the service through these very basic path like you know let's call it path one whatever just another name again and then you click on create and then you got your api defined so just a review the service is based on these upstream over here the http dot bin http bin dot org upstream and then the service is being exposed to the api consumers through this path over here slash path one so we just finished our job in the control plane and then as i said before the control plane responsible for publishing these api definition to the data plane running my local machine as a matter of fact if you go back to our data plane and try to consume the path one now we're going to get the HTTP HTTP bin dot org results as a matter of fact i can send any you know any HTTP bin org verb like you know get or uuid so on sounds good so uh and then again the api gate is the data plane as a matter of fact is sitting in the middle um i got the api consumer which is the HTTP pi sending requests to api gating and the gate is just routing the requests uh to the upstream in my case http bin dot org so um but you know again i am i'm able to send as many requests as i want nobody is preventing me nobody is controlling this exposure so that will be the case to implement policies to these routes these routes just created and then that will be the case to inject open de connect based authentication processes so in this sense the consumer should send credentials to the api gateway to and then the api gateway should work with the octa this time to make sure the credentials is fine and more than that if it's able to consume the api okay so yeah let's move on and apply the open de connect uh policy to the right to to the route we just created just i know another comments over here we can explore the specific data plane capabilities like you know the number request the data plane has been uh has processed so far the number you know the the not just the number request but you know the status codes for each one of these requests and so on so again let's take this route over here and enable the open de connect policy to it so how we do that we use the this time that's the time to use the con connect plugins as a matter of fact if you go to the route we just created and click on this add plugin button over here you're going to see a extensive list of plugins con provides in order to implement to define all sorts of policies for instance for authentication based uh policies we provide extensive lists like new to implement base authentication api keys the regular mechanisms we we usually have the api gateway to its authentication base authentication api keys mutual tls very very important open de connect that's the one i'm going to use ldat based if you want to implement the ldat base authentication process of course and so on the same thing we provide other plugins to implement security based policies like you know opa that's the base on these open policy agent like you know to implement access control policies and then we got traffic control uh plugins to implement you know canary release is to implement mocking if you will add the api gateway layer to implement caching add the api gateway layer again to integrate with your graphical well servers to implement rate limiting policies um to um to implement um you know policies like you know um to to limit the the responses coming from the uh the upstreams and so on we we also provide server less plugins in order to integrate the server well known server less infrastructures like aws lambda azure functions and so on analytics based um uh plugins to implement integration with data dog prometeus zipkins for tracing transformations policies very very important to transform requests for instance to transform requests before sending requests to the upstreams to transform responses before getting back to the consumers to enable grpc protocols to transform rest requests into graphical well requests to transform uh rest requests into kafka requests and then publishing publish events to a given existing kafka topic and so on last but not least also um plugins to implement all sort of logging processing um based on files based on stats d uh kafka again i'm using kafka this time as my log processing infrastructure tcp datastream based um udp and so on so here's the uh you know the extensive list of plugins we provide in con connect enterprise so for this workshop we're going to use again we're going to use the opend connect uh plugin so again if we click let's go back let's starting over like you know again is our service the service has got only one version the version is got uh one route defined and then for this route we're going to apply the opend connect plugin these opend connect plugins and then if you go through this page over here you're going to see extensive list of parameters you uh you might want to uh to set in order to implement you know all kinds of grants all grant all opend connect grants with octa for specifically for the client credentials grant and then that will be my first use case client credentials i'm going to use the uh octa application i created previously so let's go to the octa data control plane now is the two applications i had created previously i'm going to use this one the con client credentials the most important uh parameters of course our client client id and client secrets i'm going to use these guys over here to set my opend connect plugin in my con API gateway so if you go to document again you're going to see how to do these uh how to set the client credentials how to set the opend connect plugin to implement the client credentials flow again i'm going through you know step by step how to create the octa application and then you know how to set uh all the all the uh the the important settings to implement the client credentials again and then once you got the octa uh application in place that will be the case to go to connect again to set the opend connect plugin for the again for the client credentials grant we're going to set these only four client settings for the opend connect plugin the client id the client secret the issuer endpoint and scope and here's how you can do it using both cli if you will or the GUI you click on add plugin just like i did you click on the opend connect plugin and then you go to the uh the panel the opend connect panel to define the uh the specific settings for us to implement again to implement the client credentials so just to make sure i'm using the right id and secrets i don't think so let me uh let me update this you are supposed to use yours of course but then it's gonna be mine okay so uh we're gonna again we're gonna um configure our opend connect plugin with these specific settings over here so the client id first so let's go to the con control plane again i look for client id client id is client id paste it and then we go and set the uh the secret and then we set the secret oops the secret is down here and then we set the issuer that's my issuer you're gonna you're gonna have yours let's look for the issuer and then finally the scope i if you will if you want to set a time to leave caching for the api gateway so i kind of you know the api gateway is going to keep all the formation coming from the octa for 10 seconds only doesn't know nice for testing environments of course for production ready environments that will be a totally different settings but then again you can if you will you can set this caching over here just to to instruct the api gateway to keep these information coming from the octa id provided for 10 seconds only so i'm gonna leave it as this and then just a matter to click to go down there we are good now and click on create and then you go we're gonna see the route over here again to click the route this time we're gonna see the opend connect enabled to it so if we try to consume if you go back to the consumer and try to consume the path one route actually the same route we created before we're gonna get an error meaning that you know we are supposed to provide our credentials in order to consume the api so the the opend connect plugin supports these authentication mechanism dash a means that you know you're going to to present your credentials again the client ID and client secrets in your request over here so if you if you type dash a means that you know you're going to to present the client id again here's my client id column and your client secret and then we should be able to to consume the api now oops what have i done authorized why is that have i copied correctly x yeah there you go so uh now i'm able to consume the api because you know i have presented my correct credentials this time so of course if i present the wrong credentials i'm supposed to to get in a 401 error code meaning i'm not about to rise to consume the api so what what what's happening now so you are sending a request to the data plane with your credentials injected inside of it the data plane is going to the gocta making sure the the credentials it's fine they're okay with that octa is saying yes the credentials are fine the client id and client secrets are fine more than that octa is issuing a opn to connect a JWT token for us and then you you can take it for there so kind of you know to to to use a JWT token for other purposes so but more important than this you know we are able to consume the api using the client credential uh grants so um yeah that's it so that's client credentials uh flow again if you go back to the document over here is going to show how to uh to consume the api gateway the the api send the api request to the api gateway using your client credentials and then again the gate the octa is supposed to to to issue a token for us if you copy this token and go to uh sites like JWT.io for instance you can see you can decode the JWT token issued by octa for us so kind of the three parts of the JWT header the payload and the signature over here so I think that's it so uh any questions so far so uh and then that will be a case for you guys to try by yourselves um how you know first of all how to instantiate a data plane using your docker whatever they are your docker um uh infrastructure it could be a local laptop it could be you know a docker environment running in the cloud in the service in the dm the cloud and so on so then again that will be the case like you know to uh you to it you is exercising how to instantiate a data plane more than that how to create an api and apply the open to connect you know to get these octa integration in place so um that will be it I think um I'm going to pause now and then I'll be here if you have any questions going through the document or any questions regarding any any other uh grants or policy I have described in the document here that's great Claudio thanks um I do see there was one question in here yeah I can see yeah coming from Matthew in Matthew thanks so much for that is there a way to use keys and call rather than always calling for specing points not sure understand this one when you say keys you mean api keys I think I understand the question I think the question is rather than having the gateway need to always call out to octa to validate access tokens can it validate the json web token using the octa's public keys yes you can the introspection flow as a matter of fact is just a you know just to make sure that you know because you know during during the uh the uh JWT token issue time and the api request time a lot of things might happen and then you know that will be the case uh the api gateway again it's uh you know it's part of the token validation process and then the api gateway is making sure the token is still valid you know nothing has happened to invalid you know to to to make this token invalid so kind of you know again uh the the gateway is requesting is asking the identify octas in our case and then you know asking like you know a octa these tokens are here it's still a valid one and then octa is going to say yes or no the gateway is going to follow the octa's decision if it's good for octa is good for the api gateway that's the introspection flow is all about like you know again just to make sure the the tokens is still valid uh you know at the api request time that's the most important thing at the api request time so of course you can inject other credentials along the JWT token like you know api keys and and again any other credentials and and and then again the api gateway will be responsible checking all the credentials not just the JWT coming from the identity provider so again if the api gateway the api key is valid or not and so on so forth kind of you know that's that's the that's the the most important uh one of the most important reasons we use the api gateway like you know to make sure the uh the request is um is trustworthy to be routed to the upstreams so kind of you know again the api gateway can use any sort of authentication mechanisms like you know api keys, JWTs, introspection if you will and so on so forth to make sure the requests the requests are you know totally reliable is reliable to be to get routed to the upstream that's the point not sure if you can answer your question now but uh yeah i guess the questions um i guess the question is are there options for how it decides to validate the token um rather than relying only on actually making an HTTP call to octa so for example the you know because octa's access tokens are um they are jason wipe tokens so yeah we have the option of doing the local validation of just using the public key that octa provides yeah doing the validation right absolutely not making an hdp call yeah let me share my screen again great uh again there are the api gateway provides other plugins in order to to take care of this validation process again introspection you are totally right introspection like you know requires a full connection with the ident provider not exactly a full connection because you know uh from our side we implement a caching mechanism to uh to cache all the information coming from the octa ident provider and then the sense the api gateway not necessarily is going to the octa ident provider to make sure the the token is valid and so on so forth so kind of another the introspection yes again introspection implements a from our side a caching mechanism in order to again otherwise that will be very very um uh critical to have octa um you know um uh implementing the exactly the same service level we got in the api gateway keeping in mind the api gateway is supposed to receive a massive amount of requests that will be very very difficult to have the ident provider uh to respond for you know exactly the same amount of requests the api gateway is processing at given moment that's why very very important to implement this caching mechanism from our side other than this we provide other plugins as you can see over here there's a specific JWT plugin usually is used usually is used along with the open ed connect plugin to implement other validation steps for instance let's say before going through these introspection flow you want to make sure the signature of your JWT token the JWT token has been issued by um identity provided trusted by you that will be the case to to validate the signature of the JWT token so JWT plugin is able to do it so kind of you know in this sense that will be the local port not depending on the external identity provider to validate the token so kind of again really depends on the use case i would say like you know for the most cases for the most cases we're going to have the JWT token being used along with the open ed connect token open ed connect plugin i'm sorry to implement this validation process some steps will be um done locally by the API gateway only some other steps again the introspection step will be uh done by both the gateway and the octanet provider make sense i think that makes sense for instance there's another plugin here you can re-sign the token you have received the gateway has received from the external consumers and so on so yes totally valid questions totally important as a matter of fact it's a very important question like you know to combine these plugins in order to implement the um you know the required authentication process or validation process if you will so i don't think we would want introspect to be cashed because the reason to call would be to always get yes absolutely i fully agree with you if you don't want to implement caching for the introspection it's totally fine the only comment i got for this for for this is that you know you should keep in mind that you know for each one of the requests you're going to send the API gateway the gateway is going to send another request to the identity provider back there so kind of knows something to keep in mind i fully agree with you some cases you don't want to cash other use cases you will have to to implement a caching and so on so forth caching is good but you know you have to deal with the you know the side effects of it right so that's why you know the caching provides time to live settings and so on so forth so um that's it oh yeah that's another question here need the scope of open to connect for the client credentials no you know you need another another uh not necessarily that's the point not necessarily the open to connect scope i have to find a scope one here you know just a uh um you know just an example could be any other one oh lost lost patio not sure what happened there no that was me i'm sorry oh he's back my fault wrong but wrong button sorry uh that's great do you want to run through one more use case yeah how about the authorization code authorization code is it's cool because you know we're going to to uh to do with uh HTTP redirects like you know we go we try to consume the API and then the gateway will redirect us to octaident provider and then we're going to present our credentials and then we're going to get redirect back to the API gate it's kind of fun so again there's the second um chapter the second use case um in my document over here describes how to implement the authorization and then this you know the the first paragraph over here you know just the it's used for the user authentication processes so again client credentials is typically used for um application authentication and the authorization code is typically used for user authentication yeah so can you go ahead and show your screen again looks like we lost your screen oh i'm sorry i'm sorry yeah so then again the second uh that's the second uh use case in my document over here and then i'm just you know just a brief uh comment over here that you know addresses user authentication processes instead of you know client application authentication so then again you know first of all describing how to create the octa application this time i'm using my second octa octa application just to keep things apart i created two octa octa applications one for each one of them for each um open the connect grant so the octa authorization code is here i created before and then again if you go through my document it just it describes how to do it by yourself you don't you don't if you don't have one and then um this time i'm going to use the uh the cli just for fun just for fun i'm going to uh to use the cli to do exactly the same thing i did for the client credentials so as i said before um everything you can do using the con connect GUI you can you can do using the GUI of course and then you can do the cli and then just for fun i'm going to use the cli this time so now as you can see over here i'm seeing your request to define a new route just because it could be exactly the same route but then again i'm defining a new route and then applying your pending connect again to the second route and then using a specific setting this time the most important one is the um again the client ID client secret and the issuer so um since i'm going to use authorization code i don't need to define any scope there i'm going to use the open decon at the the standard oidc scope the open id scope so um again so let's uh first of all let's get our session one more time again as i said before we have to run this one to you know that not sure if my said my session possibly my session i uh i don't have the session anymore so kind of we're going to get these connect new session oh my my session is still valid so let me close this one uh session connect so my sessions might be valid let's try it so let's create our route using our session i need a little bit more complicated let's use the GUI much easier so again let's create another route this time we're going to call HTTP beam 2 route 2 so here's the service the version let's create a new route i'm going to call it HTTP beam route 2 we're going to add these the path is going to be HTTP beam 2 that's it interesting now we got a interesting scenario the same service based on the HTTP dot beam dot org upstream now we got two service two routes exposing exactly the same service so again the service can be consumed through these two paths over here the first one and the second one so the first one you're going to use for the client credentials the second one you're going to use for the authorization code grant and so here's the the route creation and then again i'm going to apply the exactly the same plugin for the second time and then i'm going to set only the three settings the three parameters the client id client secret and issue it so again let's go back to it is the second route i'm going to add the exactly the same plugin protecting the the the route with exactly the same plugin and then the client id is the client id i'm going to copy the second client id the client the client id we got for the second octa application the client secret and the issuer the issuer is here my issuer and then go down there and then create it so now if you go to the second route you're going to see exactly the same another instance of the the same plugin open the connect plugin of course with different settings and then let's use another browser over here just to keep things apart i'm going to use firefox now so let's let's hit the port eight thousand first of all local host or eight thousand as expected i'm getting exactly the same no route whoops exact getting exactly the same no route match and then if you try to consume it's tpp in dot uh two dot get we're going to get redirected to octa this time that's the fun port whoops so kind of that's a fun port like you know uh octa is first of all i got redirected to octa that's the authorization code in action and then octa is uh complaining about these invalid requests so the redirect rule i hasn't been uh set for this application so i got to go back to octa as you can see here the um the uh the redirects the the redirects were i allowed the only cover covers these were i over here so just a matter to i have to edit the setting over here and include oops these one the general setting and include another where i in then in my case will be local host eight thousand htp bin dot two and htp bin two get or if you another one there will be enough so i'm telling octa now that you know hey uh you are supposed to um to accept requests coming from these uri so this time if you try to consume the route again let's close the browse to start over and local host eight thousand everything's fine slash htp bin two dot get now octa is accepting uri and then i'm supposed to present my credentials again keep in mind that we are a plenty user authentication process that's why you know it's up to the user to present these credentials not not this one and then there you go like you know what happened here i tried to consume the api i send a request to the api gateway the api gateway has got the open connecting label to this route the htp two route and then since we don't have any token injected inside of it the gateway redirect us to the octa ui in order to for us to present our credentials and then we presented our credentials and then octa authenticated the user taking these credentials of course and then redirect us back to the api gateway this time with the authorization code and then the api gateway completes the grant with a requesting the jwt token to the octa identity provider so again that's the uh jwt issued by octa this time again if you go to jwt octa ui and ask for the code the token we're gonna see this beautiful token we're here this time as you can imagine is a different payload with a different payload in my sub here with my the my credentials here so that's authorization code is all about like you know again credit credentials for your application authentication authorization code to user authentication questions on this that's great thank you not seeing any questions in the chat so uh that is oh matthew does have a question is doing the off-code flow with pixie no not no not this time uh we we're not using pixie um as a matter of fact it's part of the roadmap of the product of the the plugin to implement pixie as well so not this time i know it's a common it's it's becoming a common request from our customers that's why you know very very important to implement it as well not just the flow itself but pixie to inject inside of it great that's on the roadmap then yes it is as a matter of fact you know it's kind of you know the open to connect is a it's a big one you're like you know to implement all the grants and all these you know nuances you open to connect standard you know this kind of thing yeah definitely a lot to it yeah it's one of the most one of the most critical critical ones we provide one of the most important ones we provide as a matter of fact you know i don't see uh you know mission critical application being implemented without open to connect base authentication process of course you can inject api keys along the way you can inject um i don't know um ip security white list and black list this kind of thing but then again you know there will be uh extra security policies along with the open to connect based authentication processes that's the way i see it makes sense so do you want to use the rest of the time to go through one more use case or um do you want to just wrap it up a little bit early see if any more questions are coming in yeah there's another one in this case did the api gate exchange exactly exactly so kind of you know as a matter of fact that's the standard you know it's not kong it's not octa the the authorization code uh defines the the grant like this like you know uh when we get back to the api gateway octa provides the authorization code that's why the uh the flow the grant is called authorization code and then the api gateway it's it's uh up to the api gateway to go to the identity provider with the authorization code and then get the identity provider i showed you before so that's that's if you go through the official standard you're gonna see the the flow description there that will be the case like you know to explore to show you the official documentation for the opn to connect plugin if you go to docs.kongh2.com you're gonna see this doc any option here you go to this plugin hub and then you're gonna see again the the extensive list of all plugins and then you open the connectors here and then you're gonna see the official documentation of the the plugin again implementing you know uh all the main uh uh grants and flows opaque opaque access tokens, refresh tokens, authorization code, the main ones you know if you if you come to these opn to connect standard and then you know start describing all the flows how to set you know similar you know of course that's the official documentation for the plugin but then you go i'm using exactly the same settings to implement the ones i'm describing in my document over here i think we got some diagrams in here authorization code yeah so here's the diagram over here so user browser the api gateway the identity provider and the upstream and then you know you present the credentials identity provider validates your credentials returns back to the api gateway with the authorization code and then that will be the case to to get the identity the the identity token from the identity provider now make sense so yeah we got for these we got other pages very very important pages uh specific for octa for instance we provide a specific pages you know exploring specific octa settings if you go to documents and look for octa you're gonna see uh not just the uh you know the the plugin again but i'd like to show another thing open connect idea with octa this is the uh specific page exploring the how to use the open to connect plugging with octa again going through um you know similar settings we done before that's it there's another good question here um can you show how somebody from a particular group in octa can access the api so limiting limiting an api to somebody in a particular octa group yeah exactly you know i think you are referring to you exactly this is exactly the um the last use case i'm describing it like you know that will be um these use case describing how to leverage you know the octa groups and claims capabilities you know i defining a group our octa group here a user inside of it as a matter of fact i got everything done here uh and this is in the document that you shared for this lab right yeah yeah exactly the last the last use case that will be um the case explore exactly this the these use case here like you know is wouldn't be enough to get a token you have to have a token but then the api gate is going to analyze the specific claims inside of it to make sure you if you are able or not to consume the api so the use case starts defining a octa group including a user in there assigning application creating a specific claim in here i'm testing the token i'm no i'm using the token preview as a matter of fact not testing the token using the token preview just to make sure you know i'm i'm going to get a specific claim inside of it so for instance if i am using a this time i'm using a a user which is not in my con in my octa group so that's why i don't have the claim inside of it so if i use another one i can see the token is going to be issued with this con claim inside of it so again that's the token preview using these user over here and then the token is going to be issued without the claim in there but if i run the token preview with the second user i'm going to i'm going to get the claim inside of it and that that's exactly the claim the api gate is trying to look for we'll look for and you know and make this make the decision is this because is this consumer is able to consume the the api or not so that will be the case to analyze the token more precisely if the tokens got this con claim inside of it and then we're going to again that's the cli version i i got the gui version up here you see oh just the cli just the cli version so um so that's the um the opn to connect settings this time the most important one that's the the uh that's the the most important settings now i'm saying that you know the two of them some effect so the the token first of all you have to have a token of course and then the token should have a claim inside of it named con claim and this claim should have these value over here the con group setting inside of it otherwise it wouldn't be possible to consume the api only the tokens with these scope inside of it will be able to consume the api so if you if you uh you can again i'm showing you know trying to consume the api using the first user and then i'm gonna get this forbidden here because again the first user doesn't have a token with the claim the specific claim in there and then i'm gonna use the second user user this time i'm gonna get uh and we'll be able to consume the api because the tokens got the uh the specific claim in there makes sense show can show how someone in particular yeah um hey Matthew i'm saying that's the use case you're looking for i believe am i right here yeah that's great that was the question i um yeah read out earlier yeah fantastic well that's super helpful so i think that's all i have like you know the introspection kind of you know you know i would say like you know not exactly controversial use case but you know some customers they don't want to implement it because you know is a i would say like heavy weight uh grant like you know to to go to the uh identity provider add the api request time you know for some customers they they really need this kind of validation some of the customers they just uh looking for you know JWT validation like you know validating the signature that will be more than enough i would say like you know really depends on the use case but you know again that's that's all i have for today like you know the uh the document is exploring these four use cases up here i hope you you'll find them helpful useful for you guys please connect if you need anything else if you if you have any other questions please that will be my pleasure to move on and to continue with the exciting discussions like this that's wonderful thanks so much we'll go ahead and wrap it up there then um thanks for coming hope you uh hope you got a chance to work through that that document um is available so if you're watching the replay of this you can go through the doc and and follow along with the exercises as well on your own time um so thanks claudio for coming thanks for showing us how all this stuff works and um yeah we will be back here at the top of the hour again for the last session um that will be the session i'm doing on uh api security and we'll be taking a uh i guess lower level look at sort of the parts of within an access token and it's a lot of stuff relevant to this session so we will um we'll be able to cover a lot of those questions then as well so uh with that i will see you then yeah and thanks claudio for coming thanks so very much everyone was a pleasure talking to you all thank you have a great day