High-security & Interoperable OAuth 2: What’s the Latest?

So yeah, good evening everyone. My colleague Daniel is joining us remotely. So we're here to talk about high security and interoperable OAuth two and the latest there. So I'm Joseph Henan, I'm the CTO at auth lead and hopefully Daniel is there.

Yes, hello. And I hope you can hear me.

Yes, I I don't have such beautiful Italian accent. Accent.

So France, Joseph and Francisco have have, but yes, I'm here Security and sanitization expert for off lead and yeah. So what do we have in this Talk for you. Next slide please. First of all, we are going to talk about why or two alone is insufficient for high security and interoperable applications. Then we are going to talk about what is py? Yeah. And then we'll give you a quick PY two deep dive. I'm not sure if it's actually a deep dive, but we'll give you a dive, A dive and then talk about the current status and adoption. Okay.

So if you want to operate, let's say an open insurance ecosystem on open banking ecosystem or you want to do applications using oath two that require real, really high levels of security like e-sign or eHealth or anything with finance, essentially you. So using oath two is a good idea, as I said in my earlier talk already. But just saying let's use auth two is not sufficient. And also for those that know auth 2.1 just saying use auth 2.1 is not sufficient either. Why is that? Next slide please.

So if you want to have an or if you have requirements that say your ecosystem must be really secure and it must be interal, then first of all you need to do some things to make all secure. Those things are written down in the OR security best current practice, which is an ITF draft that we are about to finish, which contains all the learnings from practice and research that we know about how to operate or ecosystem securely protect against various attacks, avoid insecure options and generally try to introduce two layers of defense.

So for example, a stone excess token cannot be misused but also prevent that it is stone in the first place. However, that document has almost 50 pages last time I counted 68 musts and must nots in that document and over 50 other requirements and recommendations. So it's not super easy to take that document and implement it in your ecosystem. Then next slide please. You could say, okay, let's use auth 2.1 because auth 2.1 is roughly AU two with the security BCP applied.

However, that's a general purpose profile which tries to solve all those problems that solves, but it gives you a lot of options and importantly it doesn't enforce any of the high security options and it is not an interoperability profile. It still gives you a lot of options. So you need to narrow that down a little bit more. Next slide please.

The, so if you just take auth, it's not interoperable by default. The spec says that in one of the first paragraphs, it has a lot of optionality in the gram types authentication methods, security mechanisms and so on. And sometimes you need bespoke solutions for very common problems. For example, how do you ask for complex consent? So for example, if you want to authorize wire transfer, then you need to transfer all those details about the wire transfer to the user, to the authorization server, show them to the user. How do you do that?

There's by default not one single mechanism to achieve that. Next slide please. And then the question is, even if you narrow down all these options and come up with your own mechanisms to do those things and implement all the security requirements in your ecosystem, does everyone follow the rules? What you probably want is to test that in your ecosystem.

If your ecosystem becomes a little bit larger, even some in when you just have some, some dozens of entities in your ecosystem, you definitely want testing open ID connect has great conformance tests which help you to do that to ensure that every participant is following the same rules, but there's nothing like that for worth. Next slide please. So this is, these are the things that we need in a high security and inable ecosystem or two gives you the authorization part, but just the authorization part, open Myd Connect gives you the authentication part and comes with conformance test.

That's great. However, it doesn't cover the authorization thing. Then of course we have order or 2.1 which gives you better security, tells you how to implement a security BCP essentially.

However, you still don't have that interoperability part. So you still need to define profile of this and this is where FPI comes to rescue, which implements not only all of those things, but also adds an additional layer of security hardening on top of all of that.

And yeah, so with that, I know that's still my part. Sorry, what is fabi? What is fabi? Fabi used to stand for financial API.

However, it turns out it's not really an API. So it was renamed to the financial API security profile, which is more fitting. However it turns out it's not really about financial thing.

So it's, it's cool, it's, it's perfectly designed to use in financial applications, but there's nothing precluding it from using it in eHealth application or whatever application you have because there's nothing application specific about this. So it was renamed to the financial grade API security profile to tell people that it's secure enough to use in financial applications.

However, it turns out that people are still confused by this because they still think this is somehow about banking stuff and finances stuff. So it was renamed again to just fpi, it's a FPI security profile. There's no for explanation for the FPI part in all of this. Yes. So what is the API security profile? That's a security and interoperability and feature profile for all two. It's usable for all high security APIs, whatever your application is. And the current version is 2.0, which is an evolution of the 1.0 based on the experience that we gathered after releasing 1.0.

So this has improved security, improved interoperability, and hopefully also a simpler development for the implementers. Next slide please. This is an overview of the five B two specifications and I'll quickly go through this. So at the bottom we have the attacker, pro attacker model, which defines what we actually want to achieve in terms of security. So it lays down all those security properties that we want to ensure and it's it's, it's like a threat model but not quite a threat model because this is more fundamental.

So concrete threats can be derived from the attacker capabilities that we define. The attacker cap capabilities themselves are defined in a very broad sense. Then on top of that we have the actual security profile. This is probably the document when you want to implement fpi. This is probably the document where you want to start reading this tells you all the dos and don'ts are a secure interoperable auth and automat connect implementation and tries to defend against all those threats that we defined in the attacker mode.

And then we have optional add-ons on top if you want to use specific features. For example, we have the message signing add-on so to say when you're additional need non-repudiation. So you want your messages to be signed so you can store them for auditing purposes and so on for later. Then we have client initiated back channel authentication if you want to have a decoupled interaction for example in our call center interaction with the customer. And finally we also have the grant management API, which tells you how to handle grants and consent.

So if you want to synchronize consent or if you have want to revoke grants or expand existing grants, which is a very common thing to do. So that was the quick overview of five P two and now Joseph will tell you some of the interesting bits and pieces of that.

Great, thank you Daniel. So yeah, we normally spend 40 minutes to an hour on this presentation, so we have a couple of minutes. So let's see. So we're just gonna quickly run some through some of the actual practical features. So FPI two, as Daniel said, it's already got the OAuth security best current practices incorporated it. This allows insecure options. It uses something called pushed authorization request, which is a relatively recent standard out of the OAuth working group that improves confidentiality and integrity for the authorization request.

And it uses something called sender constrained access tokens, which I'm just gonna quickly deep dive into. So some of you probably remember this story, I'm not picking on GitHub here. There are dozens of other stories about stolen oath tokens I could have equally talked about. But here someone that had, or two different parties that had a OAuth integration to GitHub leaked CI tokens and the end result was that the attacker got access to a whole bunch of private re git repos for a hundreds, I think at least of companies. So not something you really want.

So with a sender AC constrained access token, you start with the client creating a new P key pair and then when it makes the token request, which hopefully standard OAuth authorization code flow, people are already familiar with a standard token request. But what happens here is we add on a public key and a signature that matches that public key when we're passing it to the authorization server. Then when it passes us back that access token, it's actually bound that internally to that public key.

And what that means is that when we make the resource request, we pass the access token as usual, but we also pass a a signature based on that key. And then obviously the resource server allows access. So what this means is if your auth, if your access token gets stolen, then yeah the attacker can obviously send the resource request but they don't have the private key 'cause you've hopefully stored that in some kind of HSM or otherwise securely so that when the access tokens get stolen, the private key doesn't get stolen so there's no signature.

So the resource server will reject the request and hence the attacker can't use the stolen access token, which is something we like. FPI two has or two different options for how you do this. One is an application layer thing called Depop just uses sign jots essentially. And the other option is to just use mutual TLS, which is network layer. So both are good solutions. They both have their pros and cons. If you are stuck with a obstinate network team, deep O'S gonna be better for you.

If you've got a nice network team that will quite happily con reconfigure their TLS ingress points, then maybe mutual TLS is better. So that's sender constrained access tokens. Other things FPI two does it, it insists on a symmetric client authentication. So people are probably familiar with client secrets. The problem with client secrets is they're not really a secret because the authorization server knows them, the client developer knows them, the client knows them and who knows who else got access to them in the process.

So again, asymmetric client authentication, it's based on public private key cryptography and should be harder to lose hold of your keys. And we also have recommendations about keeping TLS secure. We require the use of pixie so that stolen authorization codes can't be used by an attacker. And I'll just talk a little bit more about asymmetric client authentication.

So again, FPI provides two different options for this. One is private key jot, which very similar to DO, it's application layer use uses sign jots. People are pretty familiar with that. And the other option is again, mutual TLS.

Again, they both have their pros and cons pretty much the same as Depop versus MTLS, sender constrained access tokens. And yeah, so I think Daniel hinted at this, we actually had a formal analysis done of the FPI two security profile. So what that means is a team at University of Stuttgart, they took the attacker model, they produced a mathematical model of that.

They took the standard, produced a mathematical model of that, threw them together and make sure that the model of the security standard did actually protect against the things that we said we were going to protect against in the attacker model. And they did find one or two things that we fixed and it's all good now. And again as Daniel said, FPI two also make sure you've got some interoperability.

So it really reduces the number of protocol options it uses that pushed authorization request, which is much easier for client developers than some of the options that came before it for ensuring integrity of the actual request that gets sent to the authorization endpoint 'cause that passes through the browser so it can potentially be leaked or tampered with it unless you use pushed authentication requests. And again, as Daniel said, for FPI 2.0, we already have conformance tests.

It's actually me that develops the test primarily I lead that team at the Open ID foundation as well as my role at auth lead. And this is actually something that regulators around the world have said that yeah, there's, there's banks in various ecosystems that they have to run these tests annually on their production systems and yeah even on production systems we have found some pretty big screw ups to be honest. But I don't have time to go into that today. Buy me a beer later. So I think you're gonna take it from here, right Daniel? Yes.

So just real quick, what is the current status of FPI two? FPI two is really close to being finalized. We have reached implementers draft which gives you a nice property, so stable numbered version IPI protection and so on. But the point really is that we are really close to final which should be released in a couple of months from now. Next slide please. So PAPI two is definitely ready to use and in many jurisdictional countries and ecosystem it is already being used as you can see here on this nice map. Next slide please.

And to, to summarize five P two is the kind of batteries included spec for high security ecosystems. It implements all the latest security recommendations. Everything we know that you should do and should avoid in order to get a secure ecosystem that ensures on the wire interoperability, which also means that you can use libraries and products that implement and you can expect them to interoperate with each other, which reduces your implementation cost. We have a very comprehensive conformance testing all the recommendations and requirements in the spec. We have feature-rich extensions.

If you have those specific use cases you can apply them and use them and there's a growing worldwide adoption and this whole five P two thing is definitely the the go-to spec. If you want to set up a new ecosystem at this point, you shouldn't bother with just saying use auth two or 2.1. That's probably not what you want. Probably not enough. Use FP two. And that's it. Thank you. So thank you everyone. So there's QR codes there for myself and Daniel if you want to connect with us on link.

And as I mentioned, we normally do a a 60 minute version of this talk and we do actually have a QR code there for the recording of that longer talk if anybody wants to see it. Alright, thank you Joseph.

Daniel, I'll take one question from the field, but then there's a keynote that some of us probably also want to go see Any questions in the room? If not, you're all dismissed. Thank you very much.

Great, Thank you everyone. Appreciate that.