API Security with USAA

Payal Pan: Hi everyone, welcome. Today we will be talking about API security, and with us we have our expert from USAA, Hieu. Hieu, do you want to introduce yourself?

Hieu Nguyen: Yes, my name is Hieu Nguyen, and I am with USAA as a security architect focused on the identity, and access management. In this presentation we will talk about USAA API security journey through an insurance claim use case.

Payal Pan: My name is [Payal Pan 00:00:36]. I'm the regional principle solutions engineer at Okta focused on all things identity, but mainly focused around custom identity, and API security side of things.

Payal Pan: This is just our safe harbor statement. It says that this presentation may have forward looking statements. You're going to see this throughout the two days in every presentation.

Payal Pan: All right, so we'll be talking about today why should businesses care about API security. Then what makes APIs vulnerable. We'll also look at the OWASP API security top 10 list, the threats. Then we'll talk about how do you go about protecting your APIs. We'll look at some of the architectural patterns that help you secure your APIs as well. Then ultimately we'll talk to Hieu on how USAA protect their APIs too. Then we will have the chat on, so you can ask questions, and answer anytime throughout the presentation.

Payal Pan: API security is a very vast topic to be covering in 45 minutes to be honest, and our hope is that you can take away some new things today from this conversation.

Payal Pan: The first part, why should you even care about API security. Let's talk about that first. What happens when there's a breach?

Payal Pan: Developer gets called lazy in most instances, and I don't think that's fair. Bugs appear in the code not because developers are lazy, or they don't care about secure code, and poor quality. It's because businesses prioritize quick delivery of code or in working function over the delivery of a more secure code that may take some more time. Ideally you want to incorporate in your tools, and your deployment process, your pipeline, and treat it as a daily part of your work, hence the shift from devops to dev secops, and your red and blue team emphasizes are very critical during this whole deployment cycle as well.

Payal Pan: While there has been a lot of focus around securing the web apps, your databases, your infrastructure, hackers are looking to find easy targets, and those happen to be APIs. APIs have become a defacto in modern application architectures. Then they tend to expose really critical data about your customers, your employees, your business data, which is why APIs have become a very high value target for these hackers, and when I say hackers these could be ethical hackers as well who are just trying to help you. APIs are therefore considered the weakest link in the applications today.

Payal Pan: Let's start with some examples of some recent breaches. This is the one where the personal data for 6.5 million Israeli voters got exposed, and this happened sometime in February. You'll see with this attack the URL here, I basically took a screen shot, but the URL here for the, or the end point for the API, basically provides information about the admins. You'll see that the response also returns the password of the admins in clear text. Now, one of the issues with this end point, this was embedded in the code of the application. It was accessible without any authentication. The first lesson learned here is always protect sensitive information, and end points with authentication, and authorization. This is going to be our team basically throughout the conversation today is just focus on authentication authorization, and get deeper into that to. Of course, amongst covering some other threats as well.

Payal Pan: Then the other part that we learned from this hack is first of all never store, or transport credentials in clear text, and never return credentials in the response as well in your JSON object. You want to limit the data exposure, and only return what's required by your client at that point.

Payal Pan: Let's look at another example. This is where Starbucks developers left API keys in GitHub public repo. Now, we see this all the time, time and time again, this type of issue shows up. Now, in this example the API key was embedded in the code, and it pretty much had a lot of power to access the user's information to be able to, and also be able to single sign-on into the user's AWS account. From there on find additional information, and basically leading to the AWS account takeover.

Payal Pan: API keys should never be used alone for authentication. API keys carry a lot of power. It basically provides keys to the kingdom. They don't really follow this principle of least privilege when it comes to providing that security, and also they tend to be long lived. You want to be sure that you're not using these, and if you are using them today please make sure that you're storing it in a secure vault.

Payal Pan: Another one is basic authentication, very similar where you're using your user name and password to authenticate against an API. The problem is every time you're passing the user name and password to access your API is where the problem lies. If you are using basic OP, and in exchange for a short-lived token, like an OAuth token, then it's acceptable. Of course, all of this has to be over HTPS.

Payal Pan: What makes APIs vulnerable? We looked at a couple of examples, and you may have seen this list, the API security top 10 list from OASP. This was released a few months ago, and OASP, they basically develop, and maintain an ongoing top 10 list of the risks related to the APIs of the organization's face. This is very similar to the top 10 web application security risks that they release every two to three years. This list also provides example attack scenarios, and mitigation techniques. The highlighted ones here are the ones that we will be focusing on. That's the broken object level authorization, broken user authentication, and broken function level authorization, but if you look at it at a very high level some of these are very similar to their browser based counterparts, like the broken user authentication, authorization, excessive data exposure. We saw that in the Israeli voter breach example where the password was exposed, security mis-configuration. This is where the attackers are looking for something as simple as a missing TLS.

Payal Pan: Injection, this is very similar to SQL injection, but your injecting malicious data within APIs, and insufficient logging and monitoring, but some of these vulnerabilities, or risks that are called out are very unique to APIs, like the broken object lvl authorization, and we'll look at this one a little bit deeper later.

Payal Pan: Last, assignment, this is where by design APIs tend to expose a lot of the implementation details. Basically the way it works is you are mapping your client inputs, and binding them directly to the code variables, and objects in the backend. For an attacker it's very easy to guess, and manipulate the API requests.

Payal Pan: Another one is rate limiting, and also improper asset management. This is where you have lack of service discovery as well as managing different versions of your APIs.

Payal Pan: Before we look at the three that we highlighted earlier I also want to talk about the NIST guidelines that we have here for securing mio-microservices. This is a very cool just document going over almost 98 controls that are listed out, and all of these tools that are available, the OWASP and the NIST publication, these should be basically used as guidelines. You, as an organization, may not need all of this from your business standpoint, or from your API standpoint, but this is a great reference for you guys to look at. Let's get deeper into the three vulnerabilities that we talked about earlier.

Payal Pan: Broken object level authorization. We'll call it BOLA from now on, but this is where the API end points expose the end points that handle object identifiers. These could be either user ID, as in the case of this Pannera Bread breach where a user can easily increment the user ID in the end point, and access another user's information. The other one is by object ID where you can access objects that you're not entitled for by just incrementing the object IDs, like the document IDs in case of this first American corporation breach.

Payal Pan: Let's see how do you go about mitigating this BOLA. First of all, authorization. That is the key. You have to make sure that object level authorization checks must be added at every function level, and it should be checked against the policy engine as well. For example, in this case you want to make sure that the user 123 who is trying to access a document 101 has access to this document, and you have to check that against the policy engine. This is where you would define your fine grained policies, and authorization rules. This can be pretty much flexible depending on what system you're using.

Payal Pan: Another example is you want to make sure that user 234 is allowed to update the profile for user 123. As you can see here the user 234 is trying to update user 123's email with his own email, and that seems malicious, so you want to avoid scenarios like this, and you want to do proper testing for these types of scenarios. This can get really complex, and hard to test, but that's what something you need to watch for.

Payal Pan: Also, you want to make sure that when it comes to using these object IDs you want to use something that's unpredictable, like the GUIDs for record IDs. That's something that you know cannot be easily guessed, and be by just incrementing. Also, you can think about tokenization, encryption, all of those options here as well.

Payal Pan: Let's look at broken user authentication. Now, this is focused on the API end points that are responsible for authentication, and must be treated very differently from the other end points as these end points, the ones focused on the authentication, are vulnerable to credential stuffing, and brute force types of attacks. These would be like authentication APIs, your password, reset APIs, MFA, end points, any of these. Like in this example with Sound Cloud. There was a flaw that was found where their sign-in password end point did not implement proper account lockout controls based on a failed authentication. What happened was the attacker could basically just continue credential stuffing, and take over the account. The recommendation here would be first of all don't even build your own authentication and MFA, and use solutions like Okta where this problem has already been solved, but if you do end up implementing a solution by yourself you want to make sure you implement account lockout mechanism based on failed authentication attempts, like maybe lockout after say five attempts for authentication, and you want to have more restrictive rate limiting policies too, so the people are not coming from different IPs, and trying to do that, and you know you let that through.

Payal Pan: And, you want to implement MFA wherever possible as well, and don't accept, when it comes to JWT tokens, if you're using that for accessing your APIs too, and you want to validate your JWTs for an initial authentication you want to make sure that the JWTs are not signed with weak algorithms. Plus, you want to make sure that you validate the authenticity of the JWT too.

Payal Pan: Let's look at the broken function level authorization. With broken function level authorization, this happens when a user can make legit calls to the API that they're not authorized to. Let's look at one example here. This is where the VENMO APIs, if you guys have looked at this one from a breach standpoint. VENMO basically provides this API. That's a public API to provide all the transactions, even for strangers, or people you don't know. VENMO does this on purpose, but there's a lot of issues with this.

Payal Pan: First of all, and it's all public. They only make it private if the user chooses to do so. The issues with this is an attacker was actually able to download gigabytes of data with this one. The biggest issues that can happen is, so if I see as an attacker I see that this user 1 is always sending regularly money to this user 2 I can easily target them for spear phishing types of attacks, so you want to be careful about that. You want to, by default, you want to make these APIs private, and only allow access for your own transactions.

Payal Pan: Another example for broken function level authorization would be where you would be easily, you can easily change the API method of the end point say from a get to a post, and be able to create, or update records that you typically are not authorized to. When it comes to access management you want to deny access by default, and explicitly grant permissions to specific roles, and only for specific functions. You want to ensure that your APIs can only be invoked by clients that need to be invoking them as well.

Payal Pan: While a lot of the responsibility falls on the developer for securing APIs let's look at some of the architectural patterns that can help you bake security during the development cycle, and also share responsibilities when it comes to security with others. While we will be focusing a lot on authentication, and authorization for the APIs today these architectural patterns will also help mitigate most of the vulnerabilities that we just saw on the OASP API security top 10 list.

Payal Pan: In a typical application architecture you have your clients. You have your external clients, your mobile client, web client, IOT, could be B2B, and you'll notice that the API traffic flow typically goes from external callers to the internal services, and this is considered the north, south traffic, and once you're inside your network there's typically not a lot of controls in place as traditionally security models operate on this outdated assumption that everything inside the organization, or inside organization's network should be trusted. Modern application architectures, if you look at them nowadays, they enable internal services service communications, like in this microservices world, this whole east, west traffic, and they can be very chatty, like I this example.

Payal Pan: The shopping cart service is trying to calculate the shipping and handling for this user, and the shipping and handling service in turn calls the customer account service to look up for the user's address, and maybe the membership level, so this east, west communication represents a very critical risk surface because of its ability to move laterally if the attacker gains access to your internal network. You want to make sure you secure communication between your client, and your services, as well as between service, so your north, south traffic as well as your east, west traffic is very critical for the operations of the microservices based applications.

Payal Pan: Earlier we saw this API gateway. It acts as a central interface for your clients using these APIs, so that your clients instead of having to call every API individually, and managing the calls there, the client can just send a single request to the API gateway, which will then route to the appropriate service in the backend.

Payal Pan: Now, while the primary function of the API gateway is routing we will see that there's plenty of other security functions, like rate limiting, managing traffics, and also access coders, and throttling, this is where it helps mitigate API risks, and the lack of resources, and rate limiting. Then also input validations that can help with risks like injection, also white listing allowable methods, authentication authorization with IDPs like Okta. Then also transformation that can help limit, and filter data from an exposure standpoint.

Payal Pan: Then I get this question all the time from customers. Hey, I have an API gateway in place. Is that enough? Isn't that enough for my API security? While the API gateway provides a lot of the key functions from securing your API standpoint you still need to be able to do the authentication authorization from a user, or a client standpoint. This is where the who has access to what is where the identity and access management solution comes into picture with something like Okta.

Payal Pan: You want to make sure that typically all your users are managed within your identity management solution, like Okta, and in that case that's where the user's lifecycle is managed. That's where the user's policies are managed, and you would not want to replicate that information, that data in the API gateway, and also manage separate policies there. Typically what would happen if the user's deactivated from their identity, and access management system, or if their policy changes, and they have a live token, that token can be immediately revoked based on their lifecycle. Versus if you were to manage all of that in the API gateway, then really there's no realtime way for the API gateway to know that this user's lifecycle has changed, so you're not getting that realtime revocation of the tokens. Then the user can continue to access your APIs.

Payal Pan: This pattern helps mitigate broken authentication, and authorization as well. Authentication as the identity provider, like Okta would provide you all the benefits from strong password hashing, account lockout mechanisms, rate limitings, MFA, all of that just builds into the solution, and also helps with the authorization aspects related to the risk where you verify the authorization policies at the user level. We'll talk about the object level later, but just for the user level, by their roles and scopes that are defined within Okta's OAuth engine.

Payal Pan: Let's look at what authentication looks like in the north, south traffic. In an application the users of clients will first authenticate against Okta, and Okta will in turn return an ID token, and an access token. These are typically JWT tokens, JSON web tokens. ID token is used for single sign-on, and getting specific user profile attributes, and the access token carry the scope of authorization on what this user is allowed to do, and both of these tokens tend to have, basically they also have an expiry time, so they could be short-lived.

Payal Pan: The access token is then passed to the API gateway. The API gateway then authenticates the client with the client ID, and client secret, and also validates the access token by checking for the proper signatures, and authenticity as well as the expiry, and some other parameters, so that's authentication.

Payal Pan: Now, let's look at authorization, what that looks like in the north, south traffic. For authorization then once the API gateway has validated the JWT token it then checks for scopes within the token to see if this user trying to access the API is allowed to do the functions that it is asking for. In this example, so the customer is able to read and write their own basically the address for their own account, but a customer service agent should only be able to read the address for this customer's accounts, and not more than that. That's where once this validation, or checking for scopes is done, then the API gateway passes the token to the service, which then responds to the client based on the scopes that are passed in the token.

Payal Pan: Now remember, OASP provides core screen authorization at this point, and it's not meant for fine grain authorizations, so something like an object level security, that's not something what OASP should be used for. Finding authorizations a lot more complex, and we'll talk about that briefly too.

Payal Pan: Now we looked at north, south traffic. Let's look at the east, west traffic. API gateways usually implemented as a lightweight... Sorry, it's actually implemented as a tightly controlled, shared infrastructure typically managed by a platform team, or even an integration team, and there's typically one API gateway deployed at the edge of the enterprise network, and it provides all the services to the APIs at the enterprise level.

Payal Pan: Now, but when it comes to your internal services why would you go through your external API gateway to talk to your internal services? For east, west traffic what I've that customers also have maybe another gateway deployed, and that's internal to your network, and that's where they use that for more service to service type of authentications.

Payal Pan: Now, monolithic gateways can do quite a bit, but when it comes to they can also become a bottleneck when it comes to continuous deployment, and development of your APIs. Gateways really have a single core function, and that is to expose your API endpoints to the external client, and route the requests to the proper services that they are trying to access. If you think about it this is a shared layer, so you want to be careful not to put a lot of business logic in this layer too.

Payal Pan: Now, enter microservices world. If you're evolving your monolithic application to the microservices within your organization applications are typically composed of fine grained services, and do a lot more than just talk externally. They also talk internally quite vigorously. This is all typically done through APIs.

Payal Pan: Now, unlike the application development in the previous architecture we saw individual microservices are built by very small teams, and they chose to use their own tools, and coding languages, and they have their own delivery cycle that's independent of other teams, and other services. Basically microservices are built independently while they communicate with each other constantly. The idea is decoupling, and the whole idea is that you want to decouple, so that they can individually fail without escalating into an application wide outage.

Payal Pan: Each service has its own entry point, and as your services grow, like say maybe hundreds of services, entry points to these systems increases as well. When entry points increase the attack surface increase, which is why it's very critical to secure this east, west communication between them.

Payal Pan: How do you go about securing communication between these microservices without having any latency? How do you go about even tracking these hundreds and thousands of transactions that happen between, even millions for that matter, between these services, and how do you scale, and manage hundreds of services via API gateways?

Payal Pan: This is where an API micro-gateway can be helpful in the architecture where you can have multiple instances of these micro-gateways where a micro-gateway is a very lightweight, scriptable, API gateway optimized to run in a containerized environment. It's deployed closer to the microservice APIs, and provides a very similar security benefit from a security benefit standpoint, similar functionality to what the API gateway provides.

Payal Pan: Microservices are designed to enforce policy, and business logics very close to the service endpoints rather than having some logic in a very centralized API gateway. These are generally provided, the micro-gateways you feel, see, they're typically provided by your API gateway providers as a solution to secure east to west traffic, and you may have heard of a service mesh. Service mesh is much like a micro-gateway. It basically controls how your different services communicate with one another, and abstract this network communication from the API business logic. The service meshes handle the service to service communication, the interactions, including load balancing, this whole validation from an authentication standpoint, service discovery, routing, and then also authentication from service to service standpoint with mutual TLS where it enables both services that are in an exchange of data to authenticate with one another. Then the JWT that's sent out from the API gateway, it also handles that from an authentication standpoint as well as use the information that's sent in the JWT for authorization purposes, and defines local authorizations as well.

Payal Pan: Local authorization with like you can do local authorizations with RBAC or ABAC based on the user attributes and roles that are set in the JWT token. You can also enforce complex, fine grained access policies that are very close to your service, and again. You can use something like an open policy agent if you'd like, or there are a lot of other solutions available, or you may bake that into your code, but that's all defined close to the service that the service mesh can help you with.

Payal Pan: I know this is a lot, and there's a lot going on here, but this is the most latest, and the greatest architecture that's being leveraged by organizations who are adopting microservices, and adopting a service mesh allows for developers to focus on business logic without having to worry about the complexities of securing the communication between the services as well as the whole network function aspects of it.

Payal Pan: We looked at a bunch of architectures here, architecture patterns that you can use as guidelines from API security from north, south traffic as well as the east, west traffic standpoint. Now, let's chat with Hieu to understand how USAA secures their API.

Payal Pan: Hi, Hieu. Can you tell us a little bit about USAA?

Hieu Nguyen: Yes, USAA is a unique organization. This is founded by military for military. Our mission is to provide our service member, associate, and their family with a full range of competitive financial products, and services. In doing so we live our USAA standard by keeping our membership, and mission first, reflect our core value, caring to each other, and keep innovating to improve the current process, and target for future.

Payal Pan: Awesome, then can you tell us about your business challenge, and the use case that we'll be talking about when it comes to API security?

Hieu Nguyen: Yes, as you know the insurance claims business is a complex one. That's where many parties are involved with different business functions, such as filing a claim from a consumer, car towing, repair estimate by adjuster, repair work by a collision shop, and rental agency, and of course many more.

Hieu Nguyen: The activity sometime intertwine with each other, and overlap their timeline. This mean functionality their crossing each other because they have communicate back and forth between parties. Currently our service reps handle a million calls just for checking on the claim status, so we want to provide a better experience for our customer in sales service, using sales service to do that, as well as reduce non-essential workload on our service rep. We want to have a digital channel for all involved party using the most modern framework, such as microservices with a strong emphasis on end-to-end security, and consumer data protection. We want to have a reusable set of API that can leverage effectively by different parties, and still meeting the privacy concern on data sharing.

Hieu Nguyen: With a proper IAM solution where we could get the right level of authentication, and authorization based on either group or user profile, or risk to create this type of application. This is the powerful paradigm in developing a business functionality exPannd with API, and everything build on infrastructure specifically designed to handle microservices.

Payal Pan: That's a great use case.

Payal Pan: Then what does your API ecosystem look like today?

Hieu Nguyen: Okay, so let's starting from the backend system first. Then we move to the front where the user coming in. We know that to build an API ecosystem the first thing we need to have all the component, critical component in place, that we have to have a great IDP system that provide rich authentication, and authorization that based on industry standard, so it can be scaled, the standard such as OIF, and OIDC.

Hieu Nguyen: The next thing is we need to have an API management platform where a developer can publish, and manage their API, and automate the whole system. Everything have to work together with the IDP to provide the authorization for the API itself.

Hieu Nguyen: Finally microservices, the modern microservices are running on container orchestration like Kubernetes, and everything on Kubernetes wrap inside the thing that you mentioned before. It's a service mesh. That service mesh provide management capability, and security function that to secure the container.

Hieu Nguyen: We move next to the next level that, okay. I think you have discussed architecture pattern before that we have the API gateway on the edge, and so when the developer using API management publish their API they will push it through the API gateway. That where at the edge we provide a protection for all the backend system, and as you talking about the edge gateway can have many function, and security is a major one that play into play. They orchestrate the whole flow of checking for the API permission, and checking for the core that's only certain domain can coming in, and checking for a QOS, your grade limiting, so API gateway managing many thing that we need from a security standpoint, and also we're talking about how to have ability to locking every transaction that coming in.

Hieu Nguyen: The other thing people can say that does a token have permission, how do you proving that. Alcohol the thing will be done inside API gateway.

Hieu Nguyen: Next we move to the application side. The application side is uniquely to provide the user identity, and that connects you back to the IDP to provide kind of authentication. It depend on the risk from the suer standpoint, from the business to see if the user coming in that perform a high level of transaction, or high risk transaction. Then you can step him up to do MFA, and so on. The application can based on the user authenticate a used identity can do a group or attribute based asset control. Based on that this is a new thing that we can see that the behavior of the application chain based on identity.

Hieu Nguyen: Finally, we talk about a user. That's critical from the consumer standpoint. They want to have the application that's customized for them, and provide them with a great authentication mechanism for user password, or go all the way to MFA with different type of using FIDO, or using WebAuth, and all the thing need to have a rich authentication engines, and we're talking about how to providing all that MFA, SMA to WebAuth and, and so on. That customize that thing for user to enhance their experience.

Hieu Nguyen: Finally, when we have an application that complex like we are talking about here that between different party, sometime the party have to ask the user for permission to share the data with them, so that where we have the privacy coming in through consent.

Payal Pan: In this specific use case that we've been talking about how are you guys doing API security for your mobile app? I know we talk about this whole ecosystem, but let's talk about your architecture.

Hieu Nguyen: Yes, this is so... It coincident that what you're talking about before we are apply in very similar pattern. From the claimant when they go in using application they will be authenticate. Every function there they will be protected, and they will go out to authenticate in, and like I say depend on not just the claimant. If I am an insurance adjuster coming in we need them to do MFA, and automatically based on that identity we kick in the MFA, but auto claimant, that they just want to check for their own status they're just using a basic auth.

Hieu Nguyen: When they have authenticate the IDP, or look at their profile, and look at their group they belong to they can authorize a correct tokens. Here we are talking about two type of token, the ID token that really used for authentication, or session management, and allocate the application to know who is the authenticated member so they can display the information on the screen.

Hieu Nguyen: The second token is really about authorization. It's an access token, and that access token is used just for API. The ID token will stay on the application. The access token will be used for API call. They're now onto step three when we send the asset token down to the API gateway. The API gateway we discussed before will check for we make the call back to say for example, to OTA to do the token introspection. They will check for the subject, issuer, timeline, all that. If it come back we take out the scope on the access token, and verify that against the scope that publish on API. Remember, on the gateway when the developer push their API into the gateway they also defined what API scope that required to get through them. That's the authorization, so one their matchup. We can go to now we allow them to invoke, to move on, route into the backend system, but we not stopping there yet.

Hieu Nguyen: We say that, "Hey, backend we need additional data." That's when we generate a party token, and that party token will be used for local authorization that you mentioned before.

Payal Pan: Okay, so that's the party token that you're passing down to your services, right?

Hieu Nguyen: Right, that's for local authorization. Mostly it will be done based on business logic. For example, that subject will be checked against the business database to see where they are on their claims. If they're asking for some status, and that's already been settled, then that call will be failed at the API level.

Payal Pan: That makes sense, and that's where you're going to be doing more fine grained authorizations like I talked about earlier, and that's going to be more closer to your service, your business logic.

Hieu Nguyen: Correct.

Payal Pan: Awesome, and how are you guys setting up... Whoops, sorry.

Hieu Nguyen: Sorry, you're back.

Payal Pan: I also have one more question. How do you [inaudible 00:43:42] between your services that looks like you guys are using neutral TLS all built in with service mesh?

Hieu Nguyen: Correct, so the service mesh right now is very Kubernetes is the STO for example. They would use the MTOS to authenticate between services, and that we began to... between service A and service B it's only authorized to talk to each other. We implement the same way with a proxy, or the cycle to do that function.

Payal Pan: Okay, then what is your... Shifting gears, what is your microservices secure development cycle looks like? Do you guys follow the guidelines from OASP, and the NIST within USAA?

Hieu Nguyen: Th correct, and the developer would go through a lot of training also. We also automate in the pipeline, and we put in the DAS, and the SAS to check for all the co-base in our repository before they publish into the pipeline. Even that the testing team will do the dynamics testing to make sure that everything fit into the Oswap, all the vulnerability, before this can be published to the gateway.

Payal Pan: Awesome, thank you Hieu, and I'm sure we'll have questions from the audience as well, but in closing I just want to reiterate that the architecture patterns we saw, actually want to keep this here so we can look at that again, the architecture patterns that we saw really help you adopt the whole zero trust security approach through the authentication on who the service or the user is as well as whether they can be trusted, and the authentication aspect on what specific permissions do they have for this service. Together these protect your environment from security threats like broken authentication, and authorization, and also this architecture helps with many of the other API risks that we saw earlier in the OASP API security top 10 list to keep your organization, and your customer's data safe.

Payal Pan: Following these guidelines, and architectures will greatly reduce this coding, the coding efforts from developers, and making your applications far more efficient, secure, and decrease the API risks all at the same time.

Hieu Nguyen: Correct.

Payal Pan: Please post your questions on chat, and also want to talk about, so we have three other sessions that are closer to this whole API security topic. If you want to go super deeper in the coding level you do have the security patterns for microservices architecture from Matt Grabel that I highly recommend. There's also API's in a regulated world if you do come from the regulated world, or you may end up there some day, definitely attend this too from Kieth.

Payal Pan: Then what's new in OIDC, and OA, this is from [Erin Paraykee 00:47:02] straight from the standards committee, so you'll hear a lot over there too.

Payal Pan: Thank you again, Hieu, and we'll wrap it up.

Hieu Nguyen: Thank you.