So, as I was introduced, I'm Ali Adnan. I'm the co-founder of Authlete, and today we're going to be talking about building your own authorization server, liberating yourself from vendor limitations. Yeah.
So, I mean, this is a, you know, this is something that we all talk about, right? I mean, whenever we want to deploy a new technology or we want to, especially in the identity space, there's always a dilemma that says, do we buy or build? And you know, earlier yesterday when I was at another talk, I really liked somebody saying that, hey, should I suss it or not? Suss it or build it?
So, I just, you know, last minute incorporated the slide. And so, when there's a dilemma in terms of, should I buy it or build it? And you reach a conclusion saying that, okay, I'll buy it.
But, so you decide to buy a SaaS service. You've got a solution within your budget, and you were able to go live within your schedule. It all looks good, right? But recently what we've heard from many of our partners and customers is that once you buy a service and it's up and running and everything looks good, you start to realize that your future really becomes dependent on your vendor's roadmap.
So, when you want to make a change or when you want to support a new feature or when you want to make any changes, you're like, ah, you know, you go back to your vendor and you said that, oh, can you support this or can you support that or this is what I want to do. And sometimes the vendor is like, yeah, yeah, sure, we'll do that for you. Or sometimes they'll be like, well, we can't do it right now because it's not on our roadmap. And then you start to realize that, ah, okay, well, I guess I'll just have to wait. You don't have control over your brand identity.
So, when you're talking about your authorization server, your vendor obviously hosts your authorization server. It's a managed service. And it's very convenient because, you know, they manage the whole thing. But what really happens is that when your users access your service, you're sending them over to your vendor's domain, even for a split second, because they're obviously managing all the access token management.
So, some companies who become to, who, who, who start to become very, um, you know, conscious about, you know, having their brand identity, ah, you know, in place, they start to feel like, hey, we don't really want to send our customers to the vendor's domain, even if it's for a split second. We want to keep them all within their service domain all the time. You don't have control over your touchpoints between your users and service providers.
Again, you're dependent on your vendor because your vendor is providing you with a managed service. So, how do your users interact with third-party services?
Yes, of course, many of your vendors will provide you with that information, but you have to ask for it, or it is provided to you by a third party. It's not something that you have full control over. And when you think about all of the above, these are pretty critical factors that you start to begin to realize that, yeah, you're dependent on someone, and you wish you would have had control over all of these aspects yourself.
So, let's do another review. If you buy a service, the pros are faster time to market.
Of course, you get a managed service out of the box. It takes care of all of your authorization workflows, and it's better suited, actually, for a new or greenfield solution without established user journeys. The challenges, of course, is that outsourcing limits customized options. We all know that now. It requires retrofitting existing UX in what the vendor provides you with.
So, the vendor would provide you with templates and will tell you that, yeah, yeah, it's customizable, and you can do a lot with it. But again, it's within those templates that the vendor would provide you with. Implementing changes are beyond standard, and there are limited deployment options, of course.
So, some people might say, you know, I'm not going to buy it. I'll build it.
So, what happens then? When you build it, you're like, well, you know, I want to build it, but I'll need experienced resources. I'll need more time. I'll need to think about maintaining and supporting it on a long-term basis. That means I'll need to invest in a team. And to keep updating and supporting the evolving standards and specifications is, again, a challenge.
So, the pros are that, yeah, you have complete control over what you're building, but the challenges are that the security is not a one-off task. You need to have a team of experts and constantly stay on top of changing landscapes of compliance and security standards. And the time to market will take longer. And that's where we come in. It's a buy-and-build model. It's a little bit of a best of both worlds, and it kind of sounds very, very similar to what we're doing. It sounds very good.
But what this actually means is that you buy the components, the building blocks from us, and you build it yourself. That's our model. We empower our customers to build this yourself.
So, you have full control over the UX and the user data. You have flexible deployment models, either on-prem or on the cloud. It seamlessly integrates into existing ecosystems.
So, somebody might say that, hey, but, you know, I'm using a vendor solution. How do I use AuthLead? Or I have my own.
Well, we can integrate with almost any third-party service, because we're an API away. And I'll explain this in the next slide. I can build my own authorization server and have AuthLead manage the token space and open standards and specifications. I can have full control. And think about this.
You know, a lot of people might say that, no, you know, I'll build it myself. But when you build it yourself, you know, do you really have developers and experts who know about FAPI? You must have heard about FAPI or CIBA, MTLS, DPOP, SDJOT, the OID Federation.
And, you know, so many of the other standards that are beginning to become more and more important while you build your own authorization server. And so, with AuthLead, you buy the components, you build the authorization server yourself, and you offload all of this complicated and difficult bits to AuthLead, who would then instruct your server in how to manage your tokens based on these open standards. The blue part is where AuthLead sits.
So, we sit in the backend of the backend of your system. What that means is that the integration with relying parties using the latest OAuth and OIDC standards, we don't use any user credentials or attributes.
So, we don't have access to your database per se. We don't manage or have access to any of your user information. You can have your IAM or your login. You can use your existing IAM and login. And we work with any third-party solutions, including your API management gateways, because we communicate with your authorization server through an API.
So, you'll just have to build a few endpoints, and we will communicate through those endpoints and empower your authorization server to be fully compliant with the latest standards almost immediately. So, we have been in the business since 2016. It's almost been eight years.
So, we are specialists in this field. If many of you may have heard about FAPI, which used to be called the Financial Grade API, and we were one of the first to be fully compliant and certified. And many of our team members, many of our senior team members, of whom Joseph and Justin, are over here at the EIC conference, they have been contributing in writing the specifications for the OpenID Foundation. Takakao Saki, our co-founder, has also been very much involved and active in contributing to industry best practices. We have a growing list of customers around the world.
We have around 100 large enterprise customers who have looked at Authlete and said, yes, we want to build this ourselves. We do have the resources. We do have the funding.
But it is, after all, quite complicated. So, if we can build it ourselves and have full control, but leave it up to the experts in doing all the heavy lifting, is really something that many of these companies realize that, wow, this is the best of both worlds. And at the end, this is the last slide, but I'd like to talk to you about a use case with NewBank, which is one of the largest digital banks in the world, based out of Brazil. They have over 100 million account holders today. And they came to us and they said, we've looked at different solutions. We've looked at different vendors.
NewBank prides itself in building everything in-house. They don't buy from vendors. But when it came to their authorization server, they needed help.
So, they were looking around and they said, oh, you know, we can buy from Authlete but build it ourselves, which means they can still be true to their fundamental values of building it themselves, but they were able to offload the complicated bit to Authlete. And so, I'd like to end my presentation with a video from NewBank, which is a testimonial in terms of how they have used our solution and benefited from it.
So, if you can please play the video, please. Oops. Can you get sound? Okay.
So, I'm sure we'll be able to sort this out. Okay. Okay. Great. We'll get the sound working. Yeah. I was supposed to embed this video. My name is Luciana Cairala. I am the general manager for Authlete. If you just play the video, please. Okay. Great.
So, I'm sure we'll be able to sort this out. My name is Luciana Cairala. I am the general manager for Open Finance at NewBank. If you just play the video, please. They feel that it's not right to share data, so and so forth.
So, we really need to... Okay. Yeah.
So, this is the video. Okay. We had a piece of the link, and that's why. We should have embedded this video into our presentation, but this is a link, and it's going through over the internet, and therefore, I think we're just making some adjustments. Sure. Yeah. You talk about the quick deployment. Yeah. Your customers, roughly, you know, how quickly can they get something running? Yeah.
So, NewBank is a really good example, a very large organization, and from first contact to when they went live, it literally took them eight weeks. So, that's the power and speed of how you can build something so powerful in such a short period of time. Anyone got a question while we're waiting for YouTube to kick in? Yes. What would be the optimal customer profile? What should be in place in an ideal situation that they benefit most from your... Okay.
So, I think there are a few customer types. One would be a bank, like NewBank, who are...
So, it's kind of interesting in the sense that people who want to build an authorization server, an IDP, Identity Management Systems themselves, would be more inclined to work with a company like us because we're empowering our customers to build it themselves. It's kind of different to how other vendors approach their customers by saying that, give it all to us, we'll manage it for you. We're saying, do it all yourself, we will empower you to do so.
So, companies who would like to build it themselves will be more inclined to come to see how we can add value to their services. Then there's also system integrators who may want to provide this service to their customers.
And so, they would think our components will be very valuable for them. Yeah. Okay. Do we have the video now? Sure. Great. Thank you. Then we'll do your question. My name is Luciana Cairala. I am the General Manager for Open Finance at NewBank. Security is definitely a key piece in delivering open finance to customers.
At times, they feel that it's not right to share data, so and so forth. So, we really need to install a system that inspires trust and that it works for customers. When we looked through all the protocols, that was something that we didn't have internal knowledge. We would have to invest a lot to build that from scratch.
Time-wise, it didn't make sense. And also, it's a bit far from our core, everything that we do internally. When I look to the markets, we found that Outlet was the best company out there with the broader experience on that, experiencing other markets as well. And the scalability component is definitely a key to us. We wanted a company that had deep knowledge in processing all the security standards, FAPI, 2.0, OpenID, other certifications. And we did have regulatory dates that we had to comply with.
And when looking to a provider, we really, really wanted to find someone that was very connected with our principles, inter-engineering principles mostly, and that could scale as fast as NewBank has done. We like to build most of the things internally because it's really important for us to have control of the full experience and deliver something to customers that is really great. We have one opportunity to really delight our customers. Once we lose this opportunity, it's really hard to convince our customers to interact with NewBank again.
One of our principles is we want customers to love us fanatically, and that's a key principle. We need to scale. We need to deliver the best service. We need to be available and reliable 100% of the time. And that's when all things come to place, like in terms of the speeds, technology, availability, reliability. Those were definitely things that we were looking at when choosing a partner in OpenFinance, that it's a strategic pillar, a strategic agenda for us at NewBank. In 12 months, we got more than a million consents. That's a huge number.
So it was really, really important someone that in a matter of one year could go from zero to a million, and in less than two years go from zero to 10 million customers. And hopefully it was definitely the provider that we felt was the right one to embark on this journey with us. Thank you. Thank you. Was there a question over here?
Yeah, we've still got a little bit of time. I've got a question about open banking. Do you support Australian open banking standards? Yes. You do?
Okay, thank you. Australian EPR, yeah. Thank you.
Okay, well, thanks very much, Ali, for that. And I'm glad we got the video to work.
Yes, absolutely. Thank you very much for that. All right. Thank you for your time.
