 and welcome to the call. Thank you for joining me today. My name's Peter Finales. I'm a principal developer advocate with your zero product unit here at Okta. And today I am joined by my colleagues, Tim and Pradeepa. I'm gonna tell you a little bit about me very quickly so you know who I am and then I'm gonna hand it over to my colleagues. They're gonna tell you a little bit about themselves. Basically, I'm an architect, consultant, engineer. I have more than 30 years experience at developing software and working in the industry. And when I'm not helping teams with the complexities and values of securing software and security systems and security principles, you can usually find me engaged in either acting or directing a show at my local theater. So that's a little bit about me. I'm gonna hand over to Tim. Tim's gonna tell you a little bit about himself. Hi all, yeah, good morning everyone. I'm Tim. I'm the tech lead for AWS in EMEA. I'm for over three years now with Okta and for over 10 years in the identity space. When I'm not working, you can find me chasing my big dream to travel to every country in the world. So far, I've been to over 100 countries and I handed over to Pradeepa. I'm Pradeepa. I'm a staff developer advocate at Okta for the OZIL product. I've around 15 years of experience developing softwares and architecting solutions. This is my first year at Okta. So when I'm not working, I usually find me reading and going for an order walk, but that has changed a lot after I had my twin daughters last year. Mostly I don't have any free time and if I find free time, I'm usually sleeping. That's all about me. Thanks, Peter, for the introduction. Thank you, Pradeepa. Next slide, please. So just before we start, we've got a little terminology slide here. We're going to explain a lot of these things as we go through the presentation, but this one's just here for a refresher for those folks who watched the video afterwards and also who might look at the slide deck as well. So it's a little bit about the terminology and a little bit of explanation on there. And if we could get to the next slide, please, Pradeepa. Then we're going to do... This is the agenda for today. So we're going to get a little bit of information here about what's coming up. And so without further ado, I'm going to hand over to Tim, who's been taking us through our first section of What Is For Zero? Yeah, fantastic. So what is Art Hero? Well, we've all heard the expression that every company is a software company, but with the explosion of products and services, in reality, every company is becoming an experience company. And we as a consumer, we want to have an experience like with buying on Amazon or watching a movie on Netflix. So organizations want to differentiate the products that they develop and the services that they provide. So it all comes down to user experience. And this is where Art Hero as a cloud platform to manage the user identities comes into play. Our goal with the Art Hero platform is to optimize digital experiences by creating frictionless, contextualized, and secured user journeys while providing the developers a flexible and very easy to use platform that is extensible and secure. On the next slide, we can see how the high level architecture of Art Hero looks like. The user journey starts on the right hand side where we have the user identity. And typically you have one or multiple web portals, smartphone applications, or different ways to allow your end users to use your services and products. Art Hero is the central part, what we can see with the universal login. So, Art Hero as a cloud platform provides you a single son on experience across those different portals. This is very important to improve the user experience and with the latest browser limitations of the blocking of like cross-site cookies and so on, it's super important to have this externalized login page. The universal login, what we provide is an hosted login and it provides a lot of features and functionality that you can easily enable and adopt to provide this frictionless user experience for all your products. First of all, we provide different ways of authenticating the user. So, you probably know that a lot of websites offering the sign in with username and password and that is okay, but it adds a lot of friction. And by using the latest methods such as password less login, so we send an ODP to an email or an SMS to the end user, lowers already the friction. If you have some sensitive applications, you can also easily enable additional factors such as the authentication with face ID, touch ID, or some other biometric factors. When we think about the user login and the way users register themselves for applications, then it's a really bad user experience when you have a large list of fields where they have to provide like a username, first name, last name, email address, and so on. For that reason, Authero provides out of the box over 60 pre-built logins with social identity provider. Social identity providers is to sign in with Google, sign in with Apple, Facebook, LinkedIn, and so on. The advantage of using them is that the sign in is frictionless, you don't have to provide any password. On top of that, you also get additional information about the user because those external social identity providers, they already have basic information about the user. As I said, first name, last name, you could also get like the date they are birth and so on and so forth. When we think about enterprise applications, then those users typically live in their identity provider of those enterprises. And we make it very, very easy to connect to your existing enterprise identity provider, such as Octa, HID, Ping, and so on. Within this identity platform of Authero, there's tons of data generated. For that reason, we have a lot of built in functionalities to stream those log files to external services from AWS. But there is also a way to easily migrate your existing users if they are stored in some external databases or some other identity solutions. What we want to take a closer look in the next slide is how the Authero authentication pipeline works. And this is the big differentiator from the Authero platform to all the other identity platforms that you can find on the market. On the right-hand side, on the left-hand side, you can see that you have the application that you want to integrate with our platform. And on the right-hand side is where the user is authenticated and gets his ID and access token. How you can use those tokens, we will tell you in the next section of this webinar. But first, let's take a closer look on the authentication pipeline. So you can see that in the blue color, there is different extension points. Those extension points we call Authero Actions. Authero Actions are pieces of code which you can write to customize the user journey. Those pieces of code, the Authero Actions are written in JavaScript. You can think of them like an Amazon Lambda and they allow you to completely customize the way the user authenticates himself, but also the way how you enrich the information of the user. Imagine you have an application which is protecting some access to insurances and by enriching the token with information about, let's say, the insurances and user has, it's much, much easier to then consume the ID and the access token that you get at the end of the flow. The way the Authero works is that we have a lot built as part of the pipeline, but it's also powerful enough to redirect to some external websites before you are completely authenticated. Why do you need that? Well, if you want to request something such as terms of services or you want to enrich the user profile by prompting for additional information, then we provide a flexibility to add that as part of the sign-in process. So you can completely delegate all the identity-related topics to Authero. In the orange color, we can also see that there is a marketplace. The marketplace provides pre-built integrations which you can literally take, track and drop into our authentication pipeline. To provide you a good example is, imagine you have an online shop and you want to sell alcohol. You're only allowed to sell alcohol when the user is over 18. So you need an identity-proving and by using our marketplace and pre-built integrations for identity-proving, you can easily add that into our authentication pipeline and you don't have to touch your existing application because you can completely delegate it and make sure that the user is authenticated at the age of 18 or older before we actually allow the access to your application. On the next slide, we can see an overview about the Authero ecosystem and all the integrations that we have. As I said, tons of pre-built integrations with social identity provider. Why is it important to have those pre-built integrations? Well, it allows you to try out those integrations faster and it also increases the time of delivering more features in a short period of time because you don't have to come up by yourself in creating all those integrations. For a lot of the features, it's basically a switch of a button to enable and try them out. On the next slide, we can see that there are even more complicated use cases when we think about SAS identities. SAS identities is when you build your own SAS service like Confluence and Chira and you want to provide for each of your SAS customers which have their own tenant and sign-in user experience that is frictionless. And in this picture, we can see different ways on how the sign-in flow of such a SAS service can look like. On the right-hand side, we can see that you have an sign-in mask where the end user knows already the tenant name, but you can also start the sign-in journey by just providing the email address of the end user. And then in the middle section, Authero can customize per SAS or per tenant how the sign-in experience looks like with a custom logo, color, and the way the user authenticate. So in the first one, you can see they can sign in with a username which is managed completely on your Authero platform, but that organization also allows the sign-in with GitHub whereas the other ones only allow the sign-in with, let's say, HID and so on and so forth. The screens that you can see here are hosted by the Authero platform. That means you can completely delegate that logic and heavy lifting. And large customers that's actually using Authero for that purpose is children confluence. So every time you sign in to an Atlassian service, Authero is running in the background to make sure that we provide this frictionless user experience. On the next slide, we can see that most people think about a platform like Authero that it's just a look inbox. And when you build your own application and if you use any of those services, yes, what you see as an end user, it's a simple login box. And in reality, there's even more components which you need. So what you typically have is sign-in with username and password and some basic capabilities to have a process to reset your own password. But in the next step, you want to reach a bigger audience. So that means you introduce the sign-in with social logins and for that purpose, you also have an increase of the users. But it means you also have to figure out a better way on how to support all those users. And with Authero, you have one central store with all the user identities. And we have pre-built components that allow your help desk to easily manage those users. With the new way of attracting more users, you get more traction on the platform. That means you have more fake accounts, you have bot attacks. And for that reason, you have to introduce some new mechanisms to fight them. So you have to verify the email. You need an email server that is scaling. You need some bot protection capabilities. You potentially add a capture if there are some more risks detected. And then in the next step, you want to improve the user journey to reach even more people. So you want to take the information that you get from the users and provide them to downstream systems, such as your marketing system, CIM systems. So organizations want to have this 360 degree view about their customers. And then last but not least, you want to expand the integration of a central identity platform into all your applications. That means it's not just a web application or a smartphone application that you start with, but you want to have one central login experience across the whole application stack that you have made be built or some organizations which you acquire to widen your offering. And for that reason, you get even more challenges. And you can see that with the full picture, custom identity is not just a look inbox. There's so many different components which you need and you can build part of that, but it takes months, even for organizations, years to build all those components. You have to maintain the components. You need some senior developers, some very experienced people who can deal with this complexity of security. You need PANTAS teams to make sure that what you have developed is also built in a secure way. So tons of challenges. And what we see is that organizations use a platform like Authero to delegate all the complexity into an ready to use solution so they can focus on their core products and they don't have to deal with that. And with that, I want to hand it over to Pratipa to tell you more on how you can authorize APIs. Thanks, Tim. Thank you so much. That was a very informative session. So whenever you hear of Authero, just remember the last slide, how many things that are ongoing and then what are the things that are behind the screens of Authero does, the components that helps to protect our data applications. So let's get started. Thanks everyone for joining. So the meat of the webinar is like securing the Amazon API gateway using Authero. So before we get started, I just want to put a pretext like, does everybody know what does an API means? Like what does it mean? API is nothing but it's an application programming interface It's a set of protocols that enable communication between different software components. So these software components doesn't have to be of the same system. For example, like you have an API gateway, but the components that are talking to the API does not necessarily be the same from the same application. So API just stands in the middle of the API. It just stands in the middle of the actual data and the client requested response. I'm sure most of you are familiar with Gmail. So I just took the basic Gmail API. So we have to understand like in, if you're talking about a RIS API, there are some basic components like respect to any API, it's a Google or Twitter, whatever, you'll have some base URL and then you have a resource. And then there is a method, whether it's a get or post. So in this case, let's say you wanted to get the profile, use a profile, the base URL is gmail.googlipace.com and then you have a resource URL to get the particular information. So Gmail V1 users is called a resource path and then it defines what method you have to use to get that particular information. So in here it's like a HTTP get request. Suppose you wanted to update some information like watch or stop, then you just have to make a post call. So this is basically an API. So what is Amazon API Gateway? Amazon API Gateway provides a solution like to create RIS APIs. You can also create other APIs as well, but just for the sake of simplicity, since we are going to secure the RIS API. So Amazon API Gateway provides a solution to procreate, publish, maintain, and secure APIs at any scale. As you look at the system, the architecture, I took it from the AWS. So this gives you a complete overview of how the API Gateway looks like. You have your web and mobile applications, IoT devices, and any other on-premises applications. As I mentioned, like these applications not necessarily have to be from the same system. So these are all distributed and they are all talking to the API Gateway. The API Gateway has Amazon CloudWatch so that you can monitor how the requests are going and stuff. So it sits between the data just like your Lambda, Kinesis, or EC2. And the applications that client can access all this data through this interface. So what is the highlight is like, if you mean that you have data and you're accessing the API Gateway, it means that it has to be secure. So API Gateway provides these are all the authorization options you can provide. So the IAM resource policies and cognitive and customer authorization, these are all the authorization options that are supported by API Gateway. The choice of using the authorization options depends on your use case. So ideally if you are living in a system outside of AWS or like if you have multiple software components interacting with each other, the customer authorization with the AWS Lambda function makes sense. All the others are actually tied to AWS system like IAM and resource policies. So today we'll just see how we can use Auth0 as an authorization server to secure the API. So what are we going to build today is like, first I'll create a Lambda. So that's the resource that we're going to protect via securing the API. So I'll connect the Lambda to the API Gateway. We'll create two Lambda so that we'll know like how the secure versus the unsecured API Gateway looks like. And then we'll create an authorizer Lambda and then we protect one of the resource path like we saw in the Gmail like, let's say we say create user and then say get user. Then we can protect one of the resource using the Auth0 authorizer Lambda. Though it's like so much explaining of the things it's actually the implementation part is very easy. So what I'm going to do is like directly go into the AWS console and then quickly build stuff. I will just open the AWS API Gateway. If you're not seeing the screen just let me know. So what I'll do is like the sake of use easy so what I'm going to do is like I'm going to use the existing Lambda function that are available. So what I'll do is like create a Lambda use a blueprint say get users Auth0 webinar it has some data so I'm just going to pick some whatever I have we need to create the function to update the code. Just starting the like quite great the function will take some time because it has to create the roles and then the city permissions team work the Lambda function once it is done should be easy. So I'm going to update the code. So what it basically means is like if you invoke this Lambda function you will just get a message going to deploy it. Okay, so I've created the first Lambda function. I'm going to test it. So what I'll do is like okay so it's working. So we'll go back and then I'll create another function with the blueprint say create user the Lambda is basically is your actual data so you can actually connect to the database can fetch your cloud watch logs and stuff I just wanted to keep it simple so that's why I didn't add much feel free to connect to your data and then you know fetch it. So I'm going to deploy this change quickly test it but two ways to test it I think this is easy okay so yeah we got the results anyway so both Lambda functions are okay so what I'm going to do now is like create the API gateway as simple as that just create an API as I mentioned like Amazon API gateway provides the provision to create HTTP API WebSocket, REST and this is a private API so we are just focusing on REST and I'm just taking the public API so I'll say build let's say all zero webinar REST I'm just going to leave everything as such okay here comes the part so like I mentioned the API gateway has resources and we have to define the method so what I'm going to do is like I have to define two resources say create user and then like create and then maybe list and then I'm going to connect it to the Lambda so first I have to create a resource and then call it getUser and this is my resource path so I'm just keep it simple so say get creating this resource currently it is not connected to any of the stuff now I'm going to hook it to the the Lambda so what I'm going to do is like in the get resource I'm going to create a method I'm going to call get and now it asks me like what kind of integration I wanted to set up for the API gateway so I'm going to use the Lambda function and maybe integration and now I have to find the Lambda function so getUser's Webinar is the one we created then I click on save it just asking me that I'm going to give permission because we are connecting it together it's asking me like do you want to give the permission for API gateway say okay so we have done the connection between the getRequest and the Lambda so you have one path this is called authorization like do you have any authorization set up currently we haven't set up anything so it shows none and then I set proxy for the Lambda this is optional like if you want to transform the request what goes to Lambda and what comes out of it you can just set up the integration request I prefer to have the formator data going between the Lambda so I used the Lambda proxy so now it's connected there's a quick way to test it so what it's done is like you're accessing the API so just say test it so you're actually calling the getUser a Lambda so it works going to quickly create another source so let's say and then now I have to add the method so what I'm going to do is create the method this is when I went to say post okay now again I have to set up the Lambda function which Lambda function I want to integrate also create this now let's say create user same same step done test it quickly it's not accepting any post method so you can just click test so now it says like user created successfully which means that the integration part is done it is working for the API gateway this is just one first step we have to actually deploy these APIs to make it available as an API HTTP API so what I'm going to do is like I've created the resource I'm going to deploy the API so we had to mention which stage you want to deploy call front okay so only when you deploy these changes it will be available so for example I don't have any resource until this so let's say I get so you can see the response I get if you want to have look at the value of put which is already deployed I'm just going to make a quick call so now the integration works perfectly the last step which is like we have done the integration now everybody can use the API gateway like Tim mentioned anybody can do a bot attack or anybody can access this API because it's public so it's better to secure the API so what we're going to do is like start securing this API we have an option called authorizer so in here I had to create an authorizer as I already mentioned authorizer is another lambda you have to mention like how the token that you receive or the authorization value that the authorization and the access token how this is going to be processed and how it's going to get evaluated so I'm going to quickly show you the code because I thought it would take sometimes I've already deployed the lambda which does the authorization part so this is going to be your authorization lambda so this will receive the token and then verifies that the token is valid or not basically it actually uses the JWKS endpoint to verify whether the key is valid or not this code is available in our OZero GitHub but I can also share it so it will actually basically check like if the document is valid like if the key is valid let's say for example you have an access token from OZero or any antiprovider and you pass through this authorizer it will actually check with the authorization server whether that particular token is issued by that authorization server so you have a series of validation like it checks for the signature of that particular token it gets the public key from the authorization server so all these things are done here just verifies whether the token is done or not once it is done like let's say if the key is valid you're going to get a valid IM policy return if not then it will say like there is an error the token is not a valid token there is one thing that we have to do is like there are couple of environment variables I'm going to show you quickly the lambda this is my authorization lambda I created a generic lambda so that I can change to any OZero application so it takes three environment variables one is like which API you're going to protect that's called an audience and then there is a JWK's URL and then this is a token issuer I'll show you how I graph this data from the OZero application dashboard so login to your OZero tenant basically you will see this page on the homepage so go to your applications so whenever you wanted to secure the API the first step is to create an API so just create an API and then say OZero webinar API and then get the endpoint so I'm going to use this it can be any URL so I'm just going to use generic so that any resource under this audience can be otherwise it will strictly match so I'm going to use this then you create an API once you create this API you get some client ID and identifier and then how long this token is valid by the just created by this application and stuff so I'm just going to leave this at the moment because we have to come back and get the value so the identifier as I mentioned is the audience so what I'm going to do is like I'm going to quickly directly change it the value I have to make sure that I use the right identifier so I'll grab it from the dashboard and then I update that it's done and the JWK's URL and the token issuer are mostly the common if it's the same tenant so I'm using the tenant for the jwk.com and the JWK is json is normally the same like your tenant name underscore well known or json so this json will have your public key and stuff so you can go to JWK.io and then sorry json lint and then see what all the values it has and then the token issuer so I'm using the my tenant so I'm using the token issuer token issuer so once this is all done I'm going to say now this 0 or the lambda will respect only the access token coming from this API because I've changed it so what I'm going to do is like create this authorizer now since it's already deployed it should work so I'm just going to quickly test it I have this token grabbed from something else like it's not from the current application so if I'm going to test this lambda it will fail so it says like it's not a valid token if you look at the logs it says like it received this token and then say there was an error saying that this token is not a valid let's say I'm going to use the proper token associated with the API which I created so if you go to the test tab and find some accessible access token I'm going to grab this token and just want to test whether my authorization lambda works so this is my even json so this is my authorization token I'm going to save it just make sure the json is in the correct format okay now I'm going to test it so if you see this lambda for that particular audience so when I grab the token it says success if you see the response this authorization lambda is giving me a principal ID and then it says like I have the authorization to invoke any API but you have to restrict it but I have just mentioned like I can invoke any API so my authorization box what I have to do is the last part is like go to your API gateway and connect your the authorization lambda which is meant for your API gateway so I have to create this authorization and say let's say Auth0 webinar authorizer and then it should show me the list of a lambda I'm going to choose my authorization lambda so we are going to use token based authorization so I'm going to say token and then the token source will be the value the header will come as authorization it can be anything you just have to mention it in your code if you want to do the validation of the token before even validating you can add it like if you want the token to have better with some number with symbols then you can validate it otherwise before even invoking it will just validate whether the token is coming with the proper specification I'm just going to create it and say grant and created so now our lambda is working I just want to test whether the authorization part is working so let me say test what I have to do is like add the token and see whether my token is working so I'm going to grab it and bring now we are testing it independently we have not tied the authorizer with any APK I'm just making sure everything is working so I'm getting the response which means that let me check yeah I'm getting the policy code for example let's say I mentioned something and then say test that will fail so okay we are good the last and final step is to connect with this authorizer with the particular stage so if you see here I'm going to quickly refresh it sometimes the authorizer will not show it in the drop down so we have two methods post and get so I'm going to just update the authorization of the get to the authorizer so click on edit so it will show it will show only in the drop down only when you add it so otherwise it will not show so now what I'm going to do is like I'm enabling the token based authorization for only the post okay it's done so it's enabled let's come to get there's none I'm just going to leave it just to show the difference between this two so now what happens is like our APA gateway is set here with the authorizer and it is connected to our Auth0 and server so what happens is like when you don't have a proper access token issued by the Auth0 then you cannot access this APA I'm going to quickly show you in the terminal so as we know let me grab the wrapper so I have to if you remember I have to pass it as authorization header and then I mean you have to pass it in the header as authorization so I'm going to grab the AP token once again see is it funny to call it now this is not my address I'm missing something I'll tell you what it will not work I'm not sure if you can guess why I have to deploy the API I've added the authorizer but I've never deployed it so currently it's not secure so if you just curl without the it will work so let's say curl and then miss this it will work see it's working what because I have I made all the changes I never deployed those changes we actually tested it only on stage by stage so only now like once so that's a part so only now you have to the API which you attached to the authorizer is available so now if you just do a curl it will not work I don't know why it will take some time to take some time to refresh so ideally what you have to do is like pass this in the authorization header and then you do a create then it will work otherwise it will fail as the other one which we have not attached to the I'm going to deploy again I'm not sure whether deployed all the resources there is a problem sometimes it will deploy on me there's the simplicity now what happens is like get I'm in the wrong one this is my webinar if I use the correct I haven't deployed the correct one I just do one more deployment because I was in the wrong path yeah just now it's reflecting because I was deploying the wrong one so it means like I'm just making a direct curl without the header it doesn't work it says unauthorized now I'm going to update call the same with the header with the token now it says great and our gate is always works because I think because we never secure so let's say it always works but you don't need the header that's all we have for the demo and I have few things to share on what's happening under the hood so what we saw was very simple things but there are a lot of things that are going underneath behind the scenes so this is what we built today one is like your client using the browser terminal but it could be from your mobile application or any IoT devices we had an access token from our OZERO anti-server which provides an access token and we grabbed the token and then we sent the token along with the request and the dotted line is what we have built so we have an APA gateway that was connected to the API and we have a JWT authorizer that is also connected to the APA gateway and before even it connects to the Lambda or your data resource it checks whether the token that has been sent by the client is valid or not so this is the overall picture let's see what happens in step by step so what the first one is like we have a request we have the token that is sent to the user the second is like this token is sent to the authorizer so the Lambda which we have written has the verification of the JWT part it has to talk to your OZERO authorization server that's why we have to give the TANNN names and the JWT signature URL so once the token is verified so it talks to the server so once the token is verified the APA gateway will talk to the Lambda if there is any problem with this other token being like the signature is not correct or this token is not valid then what happens is like it will deny and then it never makes a request to the Lambda so assuming that this token is legit so the APA gateway makes a request to the Lambda and that's why we get the responses like the user created successfully response this response is sent to the client the APA gateway has the function to format the response based on the client and that's all about that and I'm going to ask Peter if you have any questions from the audience and thank you so much thank you Pradeepan thank you Tim for both of you excellent presentations and we do in fact have a few questions from the audience so if you can well if you can help out that will be great so the first question comes from Matthew and his question is do we have any examples or documentation on implementing token exchange using an APA gateway and that went to either Tim or Pradeepan I can take that question we do have a documentation on securing APA gateway using odd zero I can if you want you can just drop a note or I will drop the resources in the chat if you could do that Pradeepan I think that would be great we have any links to that I hope that answers your question Matthew and Pradeepan we'll follow up on that next question is from Thomas we're using a similar setup and our front end requests a few rest resources upon loading on multiple landers and I've seen some network latency when loading the JWKS.json obviously as it's an HTTP request to remote data center is there a best or at least a good practice to verify token signatures in a serverless environment without loading JWKS.json from network on every load for example caching in ephemeral storage and also how should that cache be refreshed I can take this question as well since it's a network latency and stuff what you can do is the primary reason of contacting between the JWKS is to verify the signature so you can actually download the signature and you can cache it in your local storage and Lambda has an ephemeral storage as you mentioned so I can use it in .pem5 in your since it's a public key you can store it and you can get that data and then do the verification there might be SDKs that support like which I have shown is like directly call the JWKS.json and then resolve it and verify the signature you just have to look for SDK that supports looking for the the public key in your cache system I'm sure that should be done it should not take much time yeah yeah and in general I mean there's two different ways on how you can validate the access token one of them is to send the access token to the introspect endpoint I guess that is the project you currently use where you send the access token each time to the introspect the other one as mentioned is that you can also cache the key within your application and then you don't have to do those external calls every time so as long as the access token is weighted and part of that access token is a claim that tells you how long it's weighted I think typically like an hour or so that means you don't have to validate a token within that hour to make sure it's still weighted cool, excellent thank you for that question, next question is can I use C++ or is it only Java that supports it this is for which language support do you mean the custom authorizer sorry I'm not sure I've just got a I don't know if you can have any update on that question or can add some additional context to that certainly all zero I can answer from the authorization server perspective all zero is an authorization server and it follows industry standard for OpenID Connect and OAuth 2 and there are a number of endpoints that we provide as APIs so you can actually call the all zero authorization server from any language it doesn't have to be Java or JavaScript or any particular language is open to anyone and since it's a Lambda function to build the authorizer so AWS Lambda supports most of the languages even from PHP, Java C, Swift and stuff so don't think there is any limitation with the language here yeah and if the target application is written within C++ so that's typically the case when you have a desktop application then there is different as the case like the QT framework which allows you to host a website within your own application and by adding a theory to that application you basically show a browser and that browser window the full flow of authenticating the user and so on happens and then when the user is successfully authenticated you redirect basically back to your C++ application to get the access token and that's at least what I saw when a customer was having a Java application cool, thank you Tim okay we've got a couple of more minutes left and a couple more questions so that works quite well Federico's question is how does the authorizer check the token does it call slash introspect what do you call it Tim yeah it calls the introspect since we answered the last question so it calls the JWKS endpoint so that's how the authorizer verifies the token cool one last question from David, I have a question about the JWT authorizer is the code on GitHub the code of the authorizer is it it's a lambda isn't it the authorizer I presume yeah so what I have the code which I have written is in serverless framework I just showed it from the console so that you know what resources you are using so it's in the GitHub, it's in my GitHub so you can visit Hradipa P and I will share the GitHub links yeah my repository cool, excellent thank you if you could go to the next slide please Hradipa and we'll wrap up the webinar we've got some upcoming events I'm going to post some links now into the chat window and these are some upcoming events we've got on zero integration and kind of our hands on lab that we do and if you could go to the next slide as well please Hradipa then you can also I've dropped a link as well into the chat window previously and you can sign up to our zero index newsletter which will give you additional development based hints tips and tricks all around security so it just leaves me really to say thank you everybody for joining today thank you Hradipa thank you Tim for two excellent presentations and of course thank you to everybody who's joined and may this webinar possible so thank you all take care have a good rest of your day bye bye thanks for joining bye bye have a nice day