Yep. Alright, so let me introduce myself first. My name is Igor Vic and I'm principal engineer with National Australia Bank. And I've got a bad news for you. I'm afraid this presentation is not about AI and it's not, and it's not about verifiable credentials either. So today my talk is about business to business delegated authorization using O2. So let me set the scene first. A growing number of organizations today are using APIs for service delivery. So we can really talk about a rise of API economy and O2 is a defacto standard for securing API access.
And with the rise in adoption of O2, we actually really seeing the API economy take off the O2 describes delegation mainly of access for consumer use cases.
However, there is a need for B2B access delegation and the O2 protocol does support B2B, but it's more for direct access with resource owner, client access the resources under its own control. Although the standard does all, sorry, does allow possibility for client to negotiate or have a pre-arrangement with authorization server to be able to access resources.
Other resources, I haven't really seen any implementation out there in the wild that actually takes advantage of that possibility. So there is a little bit of a gap there that I'm gonna talk about today. And how can we potentially address that gap? So in this session we'll explore how the existing or two standard can be extended to support the B2B delegation of access. So let's look at the actual business use case.
So because it's a B2B kind of access, there are no humans involved. We have typically system to system access and resource owner organization is represented by a client.
The third party organization is represented by a client and there is also a resource provider. So the business use case here is that the resource owner organization, although they can use the old protocol to access its own resources held by resource provider or resource server, the resource owner organization wants to engage its own partners. It could be more than one to actually provide some service to the resource owner organization so that the resource owners organization can serve its own customers.
But in order to do so, the third party organization or client need access to the resources which are owned by resource owner organization. So there is a need for delegation of access and there are two types of access in this particular scenario. There's on behalf of access, which is a delegation where third party wants to access the resources, which is owned by ZO owner, but there's also direct access, which is already covered by our standard. So I've seen various attempts to solve this problem out in in a while, in a while.
One that I don't really want to talk about, but I've seen it is sharing of the credentials, but we don't really want to go there. So we really need something better than that.
So before we proceed, let's have a look at what is actually O2 and what it actually covers. So this is a definition directly from the O2 RFC, which says that O2 is authorization framework, which enables third party application to obtain limited access to a service either on behalf of the resource owner or orchestrating an approval between the resource owner and the service.
There is also possibility to allow third party direct access on its own behalf. There are two ways that a third party application client can obtain access to the service. Obviously one is using a delegation, but for that we need a human, we need an end user to actually grant that authorization because the whole delegation flow in OT is built on browser redirects and actual consumer or customer, human user granting access or supplying a consent. So for B2B integrations where there are no humans involved, we don't really have a prescribed coverage in this protocol to allow delegation of access.
So there is a gap.
So let's just look at the old protocol flow. This this is abstract, kind of high level fuel, sorry, flow where the client, the third party client wants to access the resources protected resources and it starts the flow by sending authorization requests to authorization server, which then gets the access gets then granted through provision of authorization grant. So the resource owner, which is a human in this particular case, will actually agree to provide some consent and agree to grant that access.
Once the authorization grant typically in the form of authorization code is being given to the client, then the client can exchange this authorization grant for access token and then use that access token as a resource server to actually obtain access to protected resources. So this delegation flow as described in the standard does not have a provision for business to business access or system to system access where humans are not involved.
So I've seen some hacks out in the wild where people are using this particular flow for B2B or system to system access where they have a admin user that actually gets involved in the beginning of the authorization flow grants the access, and then the client gets the refresh token. And then from that point on it's sort of automated and can continue in a system to system kind of fashion. Obviously that's not ideal from operational point of view and also from the security point of view.
So I would like to make a a proposal proposal.
How can we actually solve this problem by extending the existing odd protocol?
And this is the revised high level authorization flow in the new proposed B2B delegated access. So as you can see the the flow is slightly different. The authorization request starts by, the authorization request is actually issued by a resource owner client. So resource owner client will make an authorization request to authorization server and then get authorization grant back.
And then as a part of the authorization, sorry, as part of the service request to a third party or partner client, the resource owner server will pass this authorization grant to a third party client. And then the third party client will then continue as per usual outflow, hitting the token endpoint, exchanging the authorization grant for access token, and then hitting the resource server without access token to obtain access to protected resources.
So the, the flow is initiated by resource owner rather than by third party client. That's the main difference. In order to achieve this, there's some changes or extensions to the audit flow. So there is actually internet draft that proposes those changes and we have two new au sorry endpoints. One is the B2B authorization endpoint and the other is the B2B authorization revocation endpoint.
So the authorization endpoint is there to facilitate the authorization flow and the authorization revocation endpoint is there to facilitate the authorization grant management because we want to allow the resource owner to manage that authorization grant after the authorization grant is issued to a third party client.
So here is a sequence, high level sequence diagram of the flow. Hello.
So as we said, authorization flow starts by resource on a client issuing authorization request to this new proposed endpoint to authorization server authorization server ate the client and then validates the request and issues the authorization code as a authorization grant. And also issues the grant id which can be used for authorization grant management flow if required, the resource owner client then passes this authorization code to the third party client. And the third party client then can use this to obtain access token.
And optionally also a refresh token, once the third party client gets the access token, then it can access the resources at resource server. In terms of the grant management, the resource owner client at any point in time can actually revoke the access by using the revocation endpoint passing the grant. ID obviously authenticated to authorization server and then authorization server will revoke all tokens. So the third party client will basically not have access to resources anymore. So here's the example of the authorization request.
So there is a client authentication part in this request, which is, in this particular example we're using client assertion and there is a request object which is digitally signed and there's some authorization request details encapsulated in a grant detail subject. So the details here is the client ID of the third party client. When the resource owner wants to grant access to optionally resource that should be authorized, the third party client will be authorized to access all the scopes which are required for that access and also the expiry.
So in this particular request, the resource owner actually specifies the terms and conditions, so to speak, of the authorization and makes that request to authorization server in the response authorization server will basically return back the authorization code and the grant ID and will also return the details of the actual authorization being granted because what has been requested and what has been granted could actually be different subject to authorization server policies.
And in the, once the third party client gets the authorization code, then from that point on we are using the regular or token endpoint. So there will be a token request that third party client will issue two authorization server to exchange the authorization code for a access token. And optionally the refresh token, obviously the authentication is required. So this is where we have the client assertion included in this request. And you can probably note that there is no redirect URI in this request because it's not really required. This is system to system access.
There are no browsers involved, there are no redirects in the token response. The authorization server will provide back the access token refresh token, which is optional and also will inform the third party client in terms of what actual access has been granted. This will be contained in the grant details. Object in the response. So including scopes and also the expiry?
Yes,
The scopes and expiration in the access itself.
Yes, yes. But access token is opec. So the third party client cannot actually read the access token.
So that that, that basically is the summary of the, or examples of the authorization flow. There is also the grant management flow, which means that if the resource owner client decides at any point in time that it doesn't really want to allow access to its resources anymore, it can issue a revocation request to authorization server.
And the key piece of information here is the grant id, and this is how the authorization know which grant to revoke and authorization server will validate this request and then revoke all the tokens including both refresh and access tokens associated with this grant id. And if that's successful, the third party client will lose all the access at that point. So let's have a look at security considerations. So first of all, both resource owner client and the third party.
Party client must be registered with authorization server and they need to be confidential clients because we do require authentication.
The authorization server must bind the authorization code to the third party client ID as specified in the authorization request. This is to prevent the misuse of authorization grant or authorization code. So if that gets lost, it cannot be used by a different party resource owner must pass on the authorization code to third party client in a secure way.
This is not specified in the actual draft or, but that's actually pretty essential because we don't really want that authorization code to be leaked. Authorization server must not grant additional access both scopes and resources to the third party client from what has been specified in authorization requests. But however it can grant less subject to its policies and authorization server must not issue any tokens with validity greater than what was specified in authorization server, sorry, in authorization request.
But it can also issue less in terms of the scopes and sorry, in terms of the the validity. So it could be actually shorter duration. And when it comes to revocation, if authorization grant is revoked by resource server, sorry, resource owner, then authorization server must revoke all tokens including bot access tokens and refresh tokens issued to a third party client.
So that's pretty much it. So any questions?
Yeah,
Any questions from the audience? Well, here you go.
Thank you.
So the, the last slide was before thank you slide was actually very important, I believe about security considerations. Yes. The question is what, what was your idea? These considerations should be built in by design or just followed by those who consume that model, let's say.
Well they, they're kind of built by design, but they obviously need to be followed.
So, so what I'm trying to say here is the actual specification will prescribe those, some of those security considerations. But so for instance, if you talk about authentication of the clients, then authorization server that implement this specification should only allow confidential clients to be part of this flow. So that's one aspect of it. And also the rules that govern the processing of the requests and response should also be really part of the specification. So all of this security considerations a part of the specification.
Thanks for your question. Any more questions?
We've got time for one more. Okay. Thanks very much Igor. Thank you. And.
