 So warm welcome to everyone who is joining online and then in person. We have a couple of announcements. One is the Code of Conduct. We operate on a strict code of conduct. So treat yourself, treat others how you wanted to treat yourself. And we do have a privacy policy if you wanted to know how we deal with the data, how this meetup is recorded, and how the photographs are taken, and how it's being used. Please do look at the privacy policy. We are streaming this live, and we might take some photos, and then we might use it for our marketing purposes. Couple of asks for you. One is like, we have a newsletter. So we always mention about any upcoming events like this meetup, which is across the world. All our developer advocates are giving a talk, going to the meetups and going to the conferences. So that gets updated in our newsletter. If you want to know what we are working on and any upcoming conferences that you can see our developer advocates in, then you can sign up to the newsletter. And this is an internet security meetup. It's always looking for speakers. So if you have some ideas, if you want to present it, please go to this form, and then submit your idea and the title. That would be great. I'm always looking for speakers to present. So I'm going to start my session, and I'm going to ask our IT expert, Karun, to join the session. He's our principal solutions engineer. And we have got some couple of questions that we received from the social media and through our other platform, and whenever we talk to the conferences and stuff. So we thought like we listen from the experts directly. So I'm going to ask the first question. Yeah. Hi. So let's introduce yourself first. Yeah. Just to introduce myself. So my name is Karun. I have been in the identity industry for most of my life. So 23 years, and I've been handling starting from LDAP all the way to now, or OpenID Connect and all of that. That's kind of my technical background. I work mostly in the architecture space and also sometimes developing interesting stuff, basically. So that's kind of my role. And I work at Opta as a principal sales engineer. OK. What's your personal hobby other than the identity? I like music a lot. So I listen to a lot of music. And when I say music, I just listen to a wide range of music, which is like rap all the way to classic music and all that, basically. That's my hobby. OK. What's your go-to music now when you have to work? Recently, it's been more of going back to Rolling Stones and kind of getting back those, right? All right. That's fun. OK. So we should really know what's your identity music now. OK. The first question I have is people always talk about Jot, JWT, and all this stuff. So what is really Jot? OK. So Jot, JWT token is JSON web token, right? So it's basically a JSON-structured token which you can start to use for understanding who is the logged in subject and things like that, right? So essentially, it's a token which you can pass once you've successfully authenticated a user and then pass the details to the downstream application or to whoever you want to kind of share. So that's kind of the JWT token's basic tenet. And it's used mainly on single sign on kind of use cases or use cases of access control and so on and so forth. It's an encoded token. So it's not human readable at first glance, but it's just encoded, right? So it's encoded and signed. So that's kind of what it is. And you can verify whether the originator of this token is legitimate. And then you can also see the content, essentially. That's kind of the two pieces for JWT. OK. Can you elaborate more on the signing part? Let's say I'm the developer who creates this application and handles this JWT for authentication purposes. How do I ensure that this token is provided by the legit provider? Yeah, how do I verify it? So JWT token by default supports two modes of signing the token. OK. Hs256 and an RS256, essentially one as a public-private key-based key pair. So you will normally have, when you're receiving a token from somebody else, you would normally have what we call as a JWT-URI, which is where you would get the keys or the public key portion of your token signing authority. You would actually get it from that JWT-URI. You will normally use that to validate whether it's a valid token issued by whoever it claims to be. So that's kind of typically how it is validated. It also serves the purpose of some man-in-the-middle kind of scenarios being avoided because we can actually see whether it's been tampered with. So if the data in that body is tampered, then your signatures would not match, basically. So that's kind of the validation that's done. OK. So there are sometimes people say, in JWT, when they say algorithm as none, people can, without any algorithm, without verification as a developer, can, if they don't verify the token with the anti-provider, then that means that I'm not actually properly using it. Exactly. It's as good as passing clear text, essentially. So I always have to verify. That's right. So JWT needs to be always verified, whether the issuer is valid. And normally, when it's a token meant for a specific purpose, like an access token or something, JWT may contain the expiry of that information. So these are things, depending upon what you're using, you basically validate, essentially. OK. And it's always the check needs to be done. It's not like you can just take it for granted, essentially. So when we see the JWT token, we see in three separations, header, payload, and the footer. What's the significance of it? So essentially, header is telling you what is the mechanism used to build that JWT token. So it includes assigning what algorithm is going to be used, and so on and so forth. Then we have a payload, which is essentially the content. So if you parse the payload, you would see it's a JSON structured items. And we have what we call as claims inside of it. Claims are the data points that you would read, essentially. And then the last portion is basically the signature to verify whether this payload has actually been signed and provided in the same shape. So we can validate a sign to say whether it's signed by the right authority that you're connected with. So it's your IDP signing and not somebody just creating a JSON token and sending it across. The other is you can see whether the sign signature is mismatching the content or not. So basically, those are the two things being achieved with that signature payload. OK, yeah. So whoever is creating this token, the ID provider who creates the token, have to make sure that the signature, everything's intact. And there is no way that this signature can be tampered. Like, for example, if someone adds a payload, for example, this person persona is a normal user editor. And then if someone says, I changed the payload to admin, what happens? How the? So normally, the signature starts to mismatch, right? Because in, let's say, for example, RS256 use case, RS256 is a private key, public key combination. And public key is what is made aware of to the clients. So the clients only know the public key, so they can only validate. But the private key is being used to sign, right? So that signature would mismatch. And because of that, obviously, JWT validation would fail. And we would know that it's been tampered with. Somebody changed a normal user to an admin user, and all of that, essentially. OK. I'm curious about the other question. Why most of the ID providers use JWT? What is the significance of it? Or are there any other formats available? Oh, yeah. So I mean, JWT is easy to use. It's easy to comprehend from a user of the token. So it's easy for reading the token, for example. And there are libraries that are easy to do. Whereas if you're talking about other mechanisms, sometimes there is a server call involved to validate the content of the token, like we have opaque tokens. So in an opaque token concept, you just get an identifier, which you have to use. You go back and call a service to get the details of that content of the token, which makes it for a network overhead. OK. So that's why probably JWT is most widely used, because it scales to the internet scale that we need. So essentially, it allows you to scale because you don't need to go to the authority again and again to validate and avoid all this network traffic. That's the first portion. Now, there are other token formats, like Pesito, for example, is an emerging token format, which is a framework, as they call it. There is, we are trying it out ourselves. We are also trying to find out whether that makes more sense, because there is a slightly more portability and more advantages of using a Pesito token. But it's not at scale. So it really needs the audience to understand. So now, JWT has become really a significant format to use. And it avoids all these hassles of having to know deep nitty gritties about using the token. The token is super simple, essentially. OK. So JWT is like, there are a lot of libraries available. Most of the languages support. So extensible. And then you have libraries. Most platforms have libraries built, baked into the basic platform. And it's a JSON. Exactly. Everybody loves JSON nowadays. Good. This one question, what the developer is curious, is because they see the garbled character, EYK, and all the stuff, can we send sensitive information in the payload? Yeah, everybody should keep in mind that JWT is not encrypted by default. It's not encrypted unless we use JWT, which is encryption spec for JWT token. And that requires you to do client certificate and things like that. So it's a much deeper kind of integration required. And it adds complexity, obviously, because you have the exchange keys and so on and so forth. By right, the default JWT is only signed. So the content is literally JSON clear text. So you should not be attempting to add things like your API key for calling another API service or a secret or to some extent like passwords or other things. Basically, sensitive information shouldn't be normally shared through JWT without an encryption in place. So it looks like encrypted and good to go, but it's not encrypted. It's pure encoding. It's got a signature to validate the integrity of the token, but that's pretty much it. It doesn't offer anything more than that. So you should step away from adding sensitive content into the token. It may look like a simple way to do it. And maybe very lame in people won't understand it, but once you pop it into JWT IO, you can see it. Yeah, we built a tool, JWT IO. So just go there and then paste your things. Yeah, you can just paste and learn what's the content. You can do it with any JWT token that you have, unless you have a proper signature, you cannot use it in your application. You are using the application it's intended to. OK, thank you so much on there. That was a lot of information for JWT. Thank you so much. No worries. You can leave it there. And without further ado, I'm going to introduce our next speaker. So he's going to talk about IAM and security for enterprise application use cases. And I'm going to introduce him. Hi, Mani. Can you come here and take the mic? Thank you. You sent the information? The new one is an updated. Email. OK. I can get back to that. She has this shared one. So can you introduce yourself while I set up the slide? OK. My name is Mani Vanan. Shot, you can call me Mani. I work for Bank of America as vice president tech manager. I lead team of full stack software developers and devops and testers. Yeah, I'm just here to present IAM most common use cases. Of course, it has tons of use cases, but it's too short to cover in 30 minute session. But I'll just touch upon four or five basic use cases that are very generic and most commonly used in the industry. Let's get started when the PPD is ready. Before we wanted to ask, what do you like to do other than, this is a common question, we bully all our speakers. You spend a lot of time solving the IAM use cases and stuff. So what do you do other than when you're not solving the IAM patterns? Yeah, so my team is not solely focused on IAM solutions. As I said, they are full stack developers, so they have responsibilities to build other things. Basically, they are developers, so they build things. And we also have devops engineers who help us to automate the deployment and et cetera. So I have broader shadow responsibilities across STLC. Yeah, and IAM is just part of it. Unlike you guys who are solely focused on IAM part and having an expert like, you know, Karuna, yeah. What's your personal hobby? Do you like to music? Do you travel? I like photography, and I had gone to the extent where I bought a drone for myself on export a lot. And after that, Singapore has scrutinized the aerial photography in Singapore. I didn't want to take any risk, so I just stick to my Canon camera again. OK, the floor is all yours. I'm going to sit and listen to the talk. Thank you, everyone. And just as a disclaimer, so all the content and knowledge I'm sharing in this person is purely mine. Nothing related to my employer, right? So it's purely personal. So from my past experience working on several IAM integration, so I would say it's no more a, so I think before that I just want to set the context. I'm not sure if all of you are from a solution background. Can I just briefly know what you all do? You're from development background, you're self-developers or solution engineers, may I know, like, you know, yourself? Great. I know you're from development background. You're good, you're all up for an institution. Great. I would make an institution. Great. Solution, second. OK. Solution, I suppose. OK, great. You're self? I'm studying cyberosecology. OK, great. So this is, again, a diverse audience group. So I just, I'll just keep my presentation at very superficial level. I will not be diving deep into any specific thing. And this discussion is generic. It's not specific to any IAM product, you know, not AWS, not WART, sorry, not work or all zero, or ping identity. This is very generic. And I just handpicked four or five use cases because in one slide I saw when I checked Vokta presentation notes, I saw these many integration options available. I know it better. So it will be too hard to cover all of them. So I just handpicked very few use cases. And that's why I titled this session as most common integration pattern. You guys may have experience with some of these, but I'll just touch upon each of them. And I'll focus more on the use cases and best practices basis instead of diving deep into technical detail. So I think I can skip this one. So we all know what is IAM. And shamelessly, I copied this diagram from Wikipedia because I don't find anything better than this diagram that explains what IAM is. So from a legacy application point of view, so there were a lot of gray area in defining what identity management and access management is. And now this is fused into one term called IAM. So there are a bunch of servers which were dedicated for managing identities. And there were other bunch of servers which were managing access control and authorization alone. Now it's fused together into IAM products. So Vokta products is just an example of IAM management solution, right? And these are the four use cases I want to discuss today. So first one being the most common one, SSO integration and federated integration. Federated SSO integration. And second one is authorization only, which primarily focuses on what based integration. And third one is trusted application integration using certificates. And fourth one is guest applications integrations using OIDC solution. I'm sure most of you are familiar with this, but let's just see how this solution fit into solve common use cases and problems, right? So SSO is straightforward. I think it doesn't need any introduction. So let's talk about SSO. I have listed down four typical use cases where you will pick SSO and people cannot on. Typically, in most of the enterprise setting, the users are expected to key in their user ID and password. And in some cases, MFA, an access code or an extra code received through email or SMS. And in a typical enterprise setting, you have tons of applications which need to leverage this user identities to authenticate the users. And if you roll the timeline back to 20 years ago, every application has had its own identity store and access management solution. Now, once it's fused together, so we have one IAM solution sitting in the enterprise managing both user identities and accesses. So with this solution, now the applications can offload their SSO responsibilities. Otherwise, the authentication and identity management responsibility to one provider and that is coined as IVP, right? Identity Provider. And the other services or the applications are called SP, Service Provider. So these two terminologies will repeat as you try to read any IAM integration guide. Identity Provider and Service Provider. So this is typically an identity provider where this is responsible for managing the user identities as well as the authentication, authorization as well. And these are the service provider which typically serves the client, right? And in the modern corporate setting, none of this service provider will take the responsibility of maintaining the user identity, neither the authentication. Everything is offloaded to this IDP. And when user accesses these applications, he presents his credentials along with maybe MFA optionally. And this SP's service providers will route the request to a IDP identity provider and he asserts his credential, then responds back. This is the sole concept behind SSO. And the most common protocol for SSO implementation is SAML, right? And the SAML is basically an assertion that confirms this user identity. And there is already a trust established between the service provider and this IDP to trust the assertion. So let's say a user accesses this web application and the web application finds, he doesn't bring any assertion then it forwards this request to this IDP. An IDP presents a login form just to keep it simple. And the user enters this login credentials. And once he's authenticated, the IDP routes his request back to the service provider with a SAML assertion. The SAML assertion can have varying data. It's not a fixed data, right? So it can have this user's basic identifiable attributes, maybe his name or his other parameters. And as well as bunch of permissions or claims or entitlements that are many synonyms for this term claims. So that basically, you know, his authorized permissions, right? So those data can be optionally present in the SAML or it's written back to the service provider. This is how a basic SML works. Now, typically in most of the enterprise setting this SAML is as is employed to provide SSO solution but to go through the basic use cases. So you will be using SSO solution where the users are typically required to key in their credentials and the applications cannot assume IAM duties and they want to offload it to an IDP and where you want to have one stop authentication and authorization solution and you want to have a single point of solution for both identity and access management, right? So these are the typical use cases where your SSO fits in and then coming to the best practices. So this is again, irrelevant of any specific identity provider, right? This is, these are very generic use cases. And when you come to best practices, so this is from my own learning, I just summed up the past learning experiences into this list. So typically what happens is even though this system is responsible for, you know, managing the identity, the bad design with the service provider is one of the applications made cache these identity information, right? So let's say this user is ABC and ABC signs in and goes to this application and this application will like to maintain its own user store maybe for whatever reason and then this ABC is entered into its own directory, its own directory and it has a copy of it. It's already a duplicate storage and there comes the complication of keeping it in sync. So it's recommended do not cache user identity in the applications. It definitely kills the IDP purpose. Then if it has to, in some settings, yes, you have to cache the user identity as well as permissions. In that case, what happens is some identity provider provides a subscription service where the service provider can subscribe to this SSO solution. And let's say if there is any change in the user store within this IDP, let's say some users are deleted, disabled, this pushes a notification to all the subscriptions so that it can delete from its own database as well, right? And let's say if some user access is disabled or has permission changes, again, it sends a push notification to all these subscribed applications. So it's recommended, you know, first of all, not to cache it or if you cache it, then you have to be sensitive of the changes happening within this IDP solution, right? And IDP replication. So as you can see, all the service providers solely dependent on one IDP solution. And this should go down. It should bring down all other applications as well. So it's recommended you enable replication of this IDP so that you have written in copies as well as you have a well-balanced cluster to distribute the load, right? And sorry, before moving on, any question on this one? Come again, sorry. When do you need to subscribe to the event? Yeah, I mean, typically it's a good practice to subscribe to the event, okay? Mostly you may not do anything with this event. Let's say if you don't cache the user information here, there is no need to subscribe. But it's good to subscribe, even if you don't cache because in some case, what may happen is a user may have signed in and the session may be active for one hour, but somebody might disable this access in the system. Only if you have subscribed to this event, you will get a push notification to deactivate this session. Otherwise you wouldn't know, right? So those sort of notifications push you will get from the IDP, right? Okay. Anything else? Yes, if you're obviously, I mean, it's an enterprise setting. They don't just install one instance of SSO IDP instance. They have definitely redundancy and clustering setup and it's understood. But what might happen is when you create multiple domains, let's say there is one IDP and there is another IDP IDPs and if there is no enough redundancy to cover and if it goes down, then the enterprise goes down. So it's recommended you create replications and cluster so that there is no single point of failure. My more answer was on the vulnerability. Like, if there is a vulnerability into the SSO solutions, it could affect the applications which are different. Of course, it will be. Yes, it will be. So I think we didn't touch upon the security focus on the IDP. Of course, there is altogether a different topic on this area, right? But yes, you have to take care of security mechanics for the IDP solution. Otherwise, losing an IDP is losing the enterprise, right? Yeah. What is the difference? Yes. Sorry, good. I'm not kidding it. Can you repeat the question? Yeah. Yes. So we can also see the response orders of IDPs on the solution to IDPs, right? Yes. So I mean, suppose the IDP has compromised or it may not have a vulnerability in those cases to onsite the repository kind of. Within this applications? No, not in... Onsite? I mean, I don't get that. So this could be either cloud hosted or on-prem hosted, definitely. That's multiple way of making sure you have the entire set of availability covered across. But be it onsite or sorry, be it on-prem or on-cloud. Yeah, I mean, if your question is, what if we lose on-cloud or external IDP solution? Of course, you can have on-prem as well. Then there are other complications like you have to keep them in sync, right? That is there. But so the availability can be addressed in multiple ways, right? It's just not on-prem or on-cloud. You can create redundancy within the enterprise setting or you can create redundancies within the enterprise setting and as well as backups in DR sites or on-prem or on-cloud standby, et cetera. So ensuring now you get the maximum availability of IDP solutions, right? Yeah. I have one question. Sure. We have an insert directory and the replications are different. Right. The use of the same. Assuming like, let's say three different audience systems. For example, like when we get the token or it's ready to token. For example, the IDProvider, it could be any provider. When we give a token, normally we give an audience, right? Yes. We have two or three different applications. So the can, how can, let's say these three are microservices that the applications are like orders, accounts and then shipping and all this stuff. Can the access tokens be shared or how does the IDProvider ensures, you know, targeted audience? So based on the token, okay. So based on the user identities, how do you set up the claims, right? Right, yeah. Because normally we set the customer for the audience specific type of order. Correct, correct. So let's say I made an order and then that has to. I got your question. I am not too sure about it, but maybe you can cover. But my assumption is probably you will have different policies or domain based on, you know, your user criteria. Normally from an audience place, how you demark it, who is meant to receive and that stuff. Then I might want to know what like is it the is also, I use one of the seed and then the audience. So normally you mint a token for specific audience. So when they try to use that token, you can validate that, okay, this has the same audience that has been used. There are many other ways of scoping a token to just an application, right? Just by, because all of these, you know, what might be connected, each are different clients. And you can use clients to demark it, who this token is issued to. Similarly, in this entity ID, which we need, the SP's entity ID, the token is only, the SABL assertion is only minted for that entity ID. Similar to audience, but yeah, they call it audience similar to SABL assertion, but essentially entity ID is what gets used. Okay, so it means that one token minted for that application cannot be used by another application. So that's how we restrict the token. Thank you. Thank you very much. We'll move on, yeah. Anything else? Okay, thank you. So something similar as a follow up, there's a so, there is this federated applications or federated identity concept. And there is a SABL difference when it comes to federation. So let me just try to put it into some sense, right? Even when your applications rely on just one identity provider and then trust the IDP, this applications actually liberate the federated authentication, right? So in a typical enterprise setting, best examples, when you use Atlassian products, right? So you use the packet, confluence, et cetera. So you just do one sign on and then that assertion is trusted across all other applications. So they are actually federated, if you ask me, federated applications or federated integration. And there is something else called identity federation. So that is just beyond that. I didn't cover it in the slide, but just let me touch it up, touch upon, where the federation is enabled across identity provider. So let's say a big corporate has two entities. Within a corporate, there is an entity A and entity B, right? Entity A has its own employees, entity B has its own employees and both entities have different set of applications, right? But the corporate wants to provide a streamline access to its employees, where if employees will log into entity A IDP system, they should also be seamlessly allowed to access entity B's applications. So now there is a federation established between entity A and entity B. It's a shared trust between two entity providers, right? That's a nutshell. It's a broader topic, it's a complicated topic. So I do not want to dive deep into it, but just passing it for a moment if you have any questions on this. Because this is very close to SSO and there is a subtle difference between SSO federation and as well as identity federation. So I just wanted to touch upon that topic, right? Nothing much. There is no, this is federated integration. So this is basically a generic pattern, a single sign-on pattern where applications rely on an IDP and this is federated applications and integrations, right? But in actual federated identity setting, there will be multiple IDPs in different domains, right? Okay. And this is a typo, must be, sorry. I'm missing the icons there. Yeah, thanks. Okay, all right. So let's talk about authorization only integration type, right? So SSO is purely, so okay, the bottom line differences SAML SSO is authentication plus authorization service. Okay, it also authenticates you and also it provides your authorization permissions which were entitled to you. But there are scenarios where your application just needs authorization claims and what this golden standard for authorization. And this use cases is exclusive when you have authorization only recommend. And primarily when you build applications within microservices or AP based connectivity or a mobile client, which will rely solely on APS to the source or update data with the servers, right? And as well as when you have a non-human interactive integration use cases where you will not expect your users to key in his credentials. And these are the type of cases where you will use what primarily and I think what is most discussed topic today. I don't need to explain it how it works, but since we are here, I just wanted to identify three entities involved in this whole workflow. Resource owner, typically the user and a client, typically a mobile or web application which runs the UI just to keep it, just to keep the fixer straight forward. This is this client basically runs the UI and in the backend it can make the API calls to a server and then get the data back and present to this user, right? In some cases, this client can receive his authentication and based on his credentials, it can authenticate and get a token or the client itself can have a pre-built token as part of it. So this client is already trusted by this server and the client will exchange the tokens to get its data. And this is in nutshell, so what I spoke about war, this is very superficial level, but when you unpack it and then see, you have a whole bunch of options to configure it each level and layer, right? And in the list of time, we wouldn't be covering those, especially, I've been a developer as well. So the pain point with war this, okay, I can give you an example where we used one of my previous companies where I used basic authentication and then what was introduced? When we started adopting war, it really killed application performance because it has to get a token every single time then it has to pass the token every single time. So there was a performance degradation and there was a whole new bunch of guidelines to help the developers to speed up this authentication process. So one of them is basically, you have to get a timed token, which is valid for a longer period so that you don't have to get the token every single time then you have the first tokens. So it's a overkill, if you ask me, the war token process is a overkill if it's barely designed for the application, right? So the best practices should be followed so that your application performance wouldn't degrade and especially when you build API-centric clients and it's recommended you understand what in detail and then follow the best practices so that your clients can get the right clients and as well you segregate the clients based on their duties and your war token processing and validation processes comparatively faster, right? Okay, just moving ahead. So, sorry, before we move on, anything with war, I think you all know it better. So since some of you come from development background, I think you know war very well, right? Like choosing which authorization flow because all has a kind of flows. Yeah. So that based on the round trip, I see people using sharing the credentials open, not using it. So, yeah, what do you normally use which authorization flow or is the deep reuse? Plane, grand type plan, yeah, because... Yeah, yes, it's basically APIs, right? Mission to Mission, not user centering. Yeah. And the next type is, so this is a very interesting setting if you see. MTLS side, I'm sure some of you know it. So it's, so TLS has been there for a long time. Now, there is a new era of cert authentication. This is called MTLS, right? So typically what happens is you can be in a setting where your client need to be authenticated, but your client cannot probably have a common validator to share with the server, right? So if it's war setting, ideally we need to have a server which will provide the token and as well as validate the token. But let's talk about a scenario where you have a regulatory system or a common provider which will only allow authentication from approved clients, right? Maybe for a regulatory system, a lot of financial institutions may want to exchange data with them, right? But every entity participating in this data transformation should be pre-upload by the regulator, right? And probably for security reasons, they cannot share a common IDP system where the client can get some form of token, share it with server for validation. That setting may not be possible. So in that scenario, how they will ensure authentication is through MTLS. So MTLS is basically a two-way validation process where server will present its certificate to the clients. So client validates it. And this is exactly how HTTPS works, right? Your TLS works all the time. Server only presents its TLS certificate to the client and the client validates it. That's how 100% of the websites works with HTTPS. With MTLS, the client will also present its certificate so that the server will validate. So that not every single client on the internet can connect with the server, not possible. Only the approved client, which has pre-approved certificate from the server, can establish non-education, right? So in contrast to this scenario, there you can have a client which can get the token from the server and this service provider is missing here or the resource is missing here. So the client gets a token from the server and can access this service provider. This party exists, but in a regulated environment for security reason, this party cannot exist. Then this is your solution, right? So you get MTLS certificate installed so that your client is trusted and then it's allowed to establish a connection with the server, right? I'm not sure if all of you will get a chance to use this, but this is a very, I would say like very rare scenario where you have a tight security constraint to establish a client server trust and this is where the same TLS helps. So as I said, where you cannot have an authentication server shared, let's say you have an authentication server, IDP server, right? Let's say for whatever reason you cannot have an IDP server, then this is your scenario, right? How will you authenticate otherwise, right? So mostly where, you know, with regulatory it works out because when the financial institution participates in a data exchange with regulatory, they cannot nominate a third party authentication server. It even complicates the scenario, right? So you cannot have a third party server participating to regulate between the client and server and that's where you use MTLS, right? Here, how is the authenticity of the client and the server is meant to, I mean? Because this server only issues the client certificate. So let's say if it's HTTP, yes. Then you can have number of browser connecting to the server, right? Yeah, but in that case, I think the authority would be there who would be showing the certificate to the server and then it would be shared with the multiple clients. Correct, yes. In such scenario, how that is, I mean? So that will be an approved CA by the server. You said that you take improvement from? Correct, yes. Regular improvement from? Yes. Then you would get a... Yes, correct. All right. And the last one is guest identities and decorations, straightforward. So YIDC doesn't need an introduction. It's been there since long time. Okay. So let's say you have a scenario where you're hosting a non-critical application. For example, a survey application or a voting application where you're not interested in maintaining the user data or you don't care about their permissions, et cetera. Then the first decision you make is to offload their authentication management process because the moment you hold the user identities and it becomes a liability to you, right? You cannot lose it. If you lose it, then you tend to have implications. And that is when you go for this option where you will offload your authentication to any of the common identity provider. And this type of connectivity is called open identity, YIDC. Whereas as a service provider, you already established a trust with these identity provider. That is an integration process. You may be knowing it very well. And as in when the user comes to login and you give them a bunch of options now which you think is the most common IDP provider. And ideally this is offloaded to this one of these IDP provider. And this primarily writes on what protocol, then SAML, right? So what is in play here. And I'm not sure if you guys have used Amazon's Cognito, whereas Cognito gives you an option to cache this information. And I'm sure other IDP provider might also be giving that option. Though these IDPs basically authenticate, you still need the user data because you need to know who has answered the survey or who has voted for this, right? You still need to cast IDP. And most of the IDP provider, especially since I used Cognito, I just mentioned it, provides a way to still get some of the approved user attributes here. If you go to, let's say if you opt to login through your Google account, as you log in, Google gives you a warning that these information will be shared with the provider. Maybe your name, very restricted information, right? So that kind of attributes are pre-cached again in the service provider, but there is no way of recycling it. So once you cache it, you've got it, that's it. There is no way of recycling it, right? So this kind of integration is well suited for non-critical apps like survey, voting, et cetera, and where you don't want to assume the identity management liability, right? And typically it's good to offload some of the workload to a third party where you don't have to waste a lot of resources here, right? So these are the four common repeating integration types as just recalling. So we spoke about SSO, we spoke about federated integration, federated identity management, and we spoke about what authorization-based integration type, then we spoke about OIDC, right? These are four or five common repeating patterns you will see across the industries and MTLS too, right? Now, if you see the offerings, since we are at Vokta, I just picked up this screenshot from Vokta's website. These are the offerings from Vokta. So too many, right? These are the integration types and some of them still can be categorized into one of the five items we discussed, right? So I didn't do that, but if you pick, let's say this OIDC and this reverse proxy authentication will still fit into what type, right? So if you group them, it will fit into either of the four or five buckets and there may be a few exceptions as well, right? So these are the offerings and most of the competitive IDP will have similar offering, maybe under different name, right? So that's all I had for today. Anything else? Sorry. Just wanted to say thank you. Okay. Thank you so much. Thank you all. Nice talking to you. Anybody else, any questions? You can catch him offline also. He's in LinkedIn. I'll post the LinkedIn in the meetup group and then also share the slides. I can also view the YouTube stream. So if you miss any questions, whatever you have it, then you can just post it. If you want more questions, more sessions from money, you can ask him also. Thank you. He's coming all the way from Hoverfront and then to the next one. I just want to take the same moment to thank you all. Thank you everyone for joining and this meetup is sponsored by Auth0 by Okta. So this is a community run meetup. So it does not necessarily have to be someone from Okta have to run it. I'm just initiating this part. So this is for the identity community. We are evangelizing the identity and security as we grow further in the landscape of AI intelligence and all the stuff, artificial intelligence and then now it's like, the threat landscape is increasing. So it's the responsibility of the company and the community to talk about where we are actually lagging behind and then say, when you take a step forward, just tread and then see there are any security problem and all the stuff. So if you want to talk about identity and security, if you want to create awareness, it doesn't necessarily have to be exhaustive, like money share, it can be a simple use case. So it's like, how can you treat your password? How can you share? How to handle your passwords? It can be for normal layman and also for the developers. So we don't want to leave any leakage. So that's the motto of this meetup. So share anything on identity and security in this platform. This is a safe platform. Anybody else, listening to this meetup online, if you are based out of Singapore, if you wanted to come and talk, please reach out to the meetupintensecurity.com. We have a meetup group called Singapore Intensecurity Meetup. Thank you everyone for joining. We have refreshments here. Please feel free to have it and thank you everyone.