Thank you for the introduction and a very good afternoon to all of you. So today in our talk Beyond oar, our agenda is threefold. So firstly, we'll start by looking at why OAuth is so popular in today's market. Secondly, we'll look at why it might not be a good fit for user and group focus authorization. And lastly, we'll look at what are some of the new and upcoming alternatives for or so, just like any other, excuse me.
Ah, there it is. Okay, cool, thanks. So just like any other presentation, we'll start by going through what o authors will quickly skim through it. And we are going to hit a few buzzwords here. So it's a delegated authorization protocol. So in simple words, as a end user, I can grant access to a third party application to access my resources such as a calendar or a photo or any, anything for that matter. And this is achieved through a consent process where the user is presented with a consent screen based for the permissions that the application has requested. And once I consent it, I get an access token based on those permissions. And then I get to use that for invoking my APIs. The four main actors that you have here are the resource owner, which is me. I own my resource. The client would be the mobile application or the web app.
You have the authorization server. This is the entity that issues the access token access tokens based on the permissions that I have consented. And then lastly, you have the resource server. This is the one where my resource resources are hosted and it con, it consumes the access token and it gives me access to my resource. So now has become so popular in today's age because we are again in the cloud age. So we have a lot of applications that are transitioning from on-premise to SaaS, which has led to a shift in the architectural approach from monolith mono, sorry, monolithic applications to microservices. And that has led to a rise in, you know, API services and all has enabled all three areas for end users and for developers by enabling SSO capabilities, by, you know, secure communication across your individual and loosely coupled microservices and the, and in the API economy, it has led for stream streamlining the entire API access management.
The more well-known use cases of or include social media logins, you have mobile applications and you have IOT devices. I'm not going to go into details about this because again, they're well known. Now another market that or is widely used then is enterprise organizations. Now, some of the key characteristics of enterprise organizations that make it different from social media applications for example, are based on diverse user base. So they cater to a lot of different users in terms of their roles. For example, you can have employees, partners, customers, et cetera. And because of this you have a more intricate and complex access management system that is based on, let's say the users groups role memberships or contextual data for that matter. And then they're also integrated with all of their internal systems, for example, their E R P and CRM systems. Another thing that that differentiates enterprise applications from social media applications for that, for example, is dynamic access needs.
Now, as the organization evolves, there is a need for the access control requirements also to change. And because of that, so that could be because of let's say employee turnover or you can have a new partnership or just regulatory compliance. And many industries are subject to strict, you know, data security, you know, policies and requirements. And because of that, unlike let's say a few companies, which we shall not name, who sell their data for ad revenue enterprise applications cannot afford to do that. Sensitive data has to be stored more securely and there is a imperative need for these organizations to mitigate these risks and to reduce the attack surface itself so that you are not, so that you do not have any potential security breaches. So in a situation like this, the kinds of questions, the kinds of authorization questions that you ask become quite different from what you would ask for example in the social media application.
And you can boil those questions down to these four here. So within the organization, what is your role? Are you a employee? Are you a customer or are you a supplier? If you are one of them, what are the resources that you own within this organization? And then now that you own these resources, do you plan on granting access or sharing these resources with another person or another entity? And then lastly, what are the conditions under which you want to share these resources? Now if you look at this, the first three are pretty straightforward. The last one is where it gets very interesting. Now, in my experience, I've seen that these are the most common conditions based on which access control is granted in enterprise applications. The first one is user specific roles, groups, and attributes. So I want to access control based on the memberships that a user has.
And then the next one is application specific roles and permissions. So if you consider the resultant memberships of the user as a super set that you can have, the user can have subset of these memberships that is spread across multiple applications. And based on the application that the user is accessing, those certain set of group memberships have to be applied for them to get a certain amount, certain amount of access or certain access to certain resources. Another interesting one here is conditional access policies. So this basically tells you you want to grant access only if certain conditions have been met. And that can include device compliance or network locations or the risk level that is associated with a person. And then you have change in user dynamic attributes that basically says, I want the access control to change based on certain attributes of the user that are changing over a period of time.
So for example, that can include what is the role of the user in this organization or what is the phase of the project, that phase that the project is in. So if you look at all of this data, this, all of this can be classified into fine access control. So for example, let's take this example and put it across two industries. We have the trucking industry and then we have a energy company on the right hand side. So if we take those four questions, the who are you on the left, you can have a fleet manager on the right hand side, you have the company itself. And then what do you own? So the fleet manager owns a bunch of trucks and he owns the data that is associated with these trucks. So that can include for example, fuel consumption or your engine diagnostics. And on the right hand side you have super secret web wind turbine design document that's going on.
So on the right hand side, the fleet manager wants to give access to a bunch of entities there, maintenance shop, insurance company, fleet broker. And then on the right hand side, the energy company wants to give access to certain set of employees to those documents. Now the conditions over here can be for the insurance company, they have to log in with a certain amount of LOA points only then they can get access, or you can have based on realtime data or a valid contract that they had signed. And on the right hand side, let's say you have 50,000 employees, you want to filter it down only to certain set of users that have a certain role and that belong to a certain department and you know and are explicitly assigned to this document, to this project. Now if you take a complicated scenario like this and you try to implement it, use purely using oath, then the very strengths of oath become its weaknesses.
So for example, the authorizing function that or two offers becomes a self authorizing function. So what that basically means is it is a ALICE to Alice sharing, it's not a ALICE to Bob sharing. So I cannot let my, the fleet manager cannot, cannot manage his data by sharing it to your, sorry, yeah, by sharing it to you know, the other entities that we spoke about. And the consent access is very limiting in the sense that I can only consent it, but I cannot control these accesses that I have. Scope permissions or all your scopes are predefined, they are static. So due to this inflexibility, it struggles to keep up with changing business requirements. Similarly, with user claims, you can have sufficient amount of data in your access token or your ID token for that matter. But if you take that data for fine grain access control, you're going to stuff too much data within your access token.
And that's going to get bloated. And you're going to have per, sorry for the images, it's a little here, but you're going to have personal, personally identifiable information within your claims. So because you have too much data that can lead to, you know, exposure of sensitive data. So in scenarios like this, what started off with a, Hey, why don't we use OWA for this scenario, it's going to end up with a more grim situation was, oh, why not? Or why should we start looking at some other alternatives? So this is a quick example of what, so those user claims that we spoke about is you, if you stuff them in your tokens, on the left hand side is what JWT two token is supposed to look like. It's supposed to be nimble, it's supposed to be agile, not enough, just enough data about the user.
But then if you take a fine grain access control and you put it in there, you're going to have this bunch of data in here. You're exposing too much information about the user. So if you take a situation like this and you extrapolate it and put it across an organization where you can have 2000 or 3000 such applications, then the issues become that much more a aggravated. So to summarize the issues you or does not pro, it has limited fine grade access control systems. It does not provide dynamic access, it does not allow party to party sharing and it can lead to bloated JWT tokens, which in turn leads, you know, net network latency and exposing too much sensitive information. So in scenarios like this, what enterprise authentic, what enterprise applications need is a system that is capable of separating the decision making process from your application or your system that is actually requesting the access.
So that can be achieved through a agnostic decisioning service, otherwise known as a policy decision point. By doing so, all your policy engines, which are on your right hand side, are irresponsible for making your decisions and for defining the rules. And that can be possible via rback aback P back, or you can also have a more hybrid model where you can, you don't use one or more such implementations. And on the left hand side where you have your interfaces is where you, you can use rest, you can use claims or we or our heroes emerge here, which is user managed access and grant negotiation and authorization protocol.
So, so let's dive a little into what UMA is. Now we are not going to go into the technical details, we'll just skim through what the protocol does. So UMA is an extension of or two similar to you know, pixie or token author, the token introspection endpoint. What this basically allows is a party to party authorization. So initially, which was Alice to Alice sharing now supports Alice to Bob sharing. And it is a more user-centric appro. It takes a user-centric approach in the sense that as a resource owner, I have more power over what are the res, how is, how are the resources that I can manage and how can I control them? So yep, so that's a good one. And then you also have authorization as a service, which means within one authorization server you can have multiple resource owners and multiple resource servers talking to the same server.
And if anyone is familiar with the Zack Mill approach, conceptually, many of the actors that are available in ZMI are similar touma. So for example, you have the P P P DP and the P I P, they are conceptually the same. So now if we look at the OR flow that we had here in the first screen, all I did was I rearranged them a little. And then the arrows are the same thing that decide how that show you how the communication happens. So now if we take this on, we have to convert it to uma. The thing that gets added over here is your requesting party. So this is the bob in this scenario. So previously, which was just Alice's, now Bob Alice is still Alice, she still owns all the resources. She still decides what are the policies that have to get applied for these resources.
Resource server is the same, the definition remains the same. It is the system that hosts all your APIs and it knows what are the permissions that are required. The authorization server is the brains of the organi of the architecture. And then it evaluates all your incoming requests, it applies the policies, and then it makes appropriate decision. And the flow behind this is the resource owner is going to register all of the resources with your authorization server. So for example, in the energy company scenario where you had that document, the resource owner is going to make a list of all the documents. A very simple example list of all the documents is going to say, I need view, download, edit permissions, and it's going to register. The resource owner is going to register them. So once the resources are registered, the client is gonna make call to the resource server for a particular resource requesting for a particular scope.
Then if it's unauthenticated call the ask the authorization server gives you back a permission ticket. The permission ticket is associated to that resource and scope that the client requested. And then the, the communication happens between these three, these three actors that we have on the right hand side here. And this is where you have a synchronous consent. So what this means is because the resource owner, Aldi has defined all the permissions, there is no need for any person to sit and stare at a screen saying, okay, at what time am I going to get a consent that I have to approve? So once that happens, you're going to, once the authentication happens, you can have a couple of ways in which you can do it either through claims gathering or claims pushing. Then you're going to get back requesting party token and then the client sends it back.
And if everything is a okay, the resource server gives you back access to your resource. Now this in a, this is a bird's eye view of how UMA works. Now because you are in a party to party scenario, there are many industries across which UMA can be applied. For example, you have in smart houses, you can apply it across financial services, supply chain management among many. Now let's take a step back. Again, like I said, umma is a extension of owa. Now if you take a step back and you look at all the specifications that were developed for OWA over the years, I am familiar with a few of them. I've read the specifications. But you, if you ask a newcomer to come and read all this, it's a little overwhelming. And that is the same question that even the developers, the creators of or started asking is this do.
So in the future, if we have to add more specifications, do we keep adding to this list? If so, how many more are we going to add? Or is there another alternative that we can look at? So this is where the questions came in saying, looking at the stuff that we have learned so far and looking into the future, what is an alternative for Oath? And the answer that they came up with is not what So alternative for this was actually the grand negotiation authorization protocol. Now it's pronounced in different ways. I've heard gunna g nap, but the creators call it gunna, I'm gonna stick with that. So the whole purpose of creating this protocol was to address the limitations of or 2.0 and try to keep things more consistent and simple. And the most important thing here is Ramon reliance on the grant types.
I've had many hours conversations with various clients saying, okay, which grant type are we going to use based on your application and based on your use case. But the most important thing that you get out of Ghana is that question goes away altogether and you're saving a lot of ours there. And then it also lets you question some of the protocol elements of what such as, do you really need a client id? Do you need, do you really need a client secret or can you replace that with something more secure? So all of this led to the design. You know the, all of these design protocols is what drives gna and that is your intern registration and inline negotiation. So in simple words, what those two mean are so unlike your, where you have your authorization endpoint, device code, user code, registration code, you have a bunch of endpoints with this.
There is only one endpoint that the application gets to call. And that is irrespective of what type of application is it? Is it a single page app? Is it a web app, is it a mobile app? You don't care about what app it is, you just call one single endpoint to start off with. And so because of that, now authorization servers do not have to expose a discovery endpoint anymore where they have to show all the registered URLs. So that's in short, that's what those two mean. And then user interaction flexibility basically means now that the application has sent the request, there is a negotiation process that happens between the client and the authorization server to say, what are the ways in which we can communicate? Are we going to do it via a redirect url? Am I going to launch something in my application?
Are we going to do it via a user code flow? So all that happens via this, and then it's all the communication is based out of json. So the data is more readable and it also supports for richer types of interactions and data types. And lastly, cryptography, key proofing and presentation. This here removes the dependency on the client's secrets protocol element of or 2.0. And then it enables more secure communication through a use of cryptography keys where the communication between the client and the authorization server is used via is based out of one key. And the same key is used for generating the access to bo bind it to the access token as well. So if we look at a generic request in the response format in Ghana, so the client starts off by saying, we have 30
Seconds,
Sorry. Yeah. The client starts off by saying, this is the information that I have about the user, this is the information that I want. And then a couple of other things. And then you get back a response from the authorization server based on that data. The most important thing over here is the interactions that we spoke about. So if your app supports only, let's say, redirect your and launch app, then the authorization server is going to come back and say, I'm not going to support these two. So these are the only ways in which we can communicate with each other. So on a very high level, this is what UMA and GNA are. So the idea behind all of this is to what are the ways in which you can reduce development effort on both end users and for architects in terms of designing your products so that you don't spend too much time trying to answer the same question multiple times. And then it's the Ghana protocol keeps it consistent so that you know exactly what has to happen without asking too many questions again to the users. I have a couple of most slides, but we're not going to go through it. We're out of time. So I'll just came through it if the button goes through.
Yes, we go there.
Thank you so much. Yeah,
It just FYI this, this was my first time, so ignore the first hesitant few minutes that I had.
It's really good. Thanks. Thanks for your insights.
