Fireside Chat: How OpenAI and Axel Springer Made Identity a Growth Engine

Hello, everyone. I'm John Tolbert, Director of Cybersecurity Research here at KuppingerCole, and today I'm joined by Jeff Hickman, Head of Customer Engineering at Ory.

Welcome, Jeff. Thanks, Tom. Happy to be here. Today we're going to have a little presentation and then a fireside chat. We're going to talk about how OpenAI and Axel Springer made Identity a Growth Engine.

So, a little logistics info up front. Everybody's muted centrally, so there's no need to mute or unmute yourself. We're going to do a couple of poll questions, and we'll talk about the results near the end. You can also submit questions at any time in the live storm control panel. And then lastly, we're recording the webinar, and both the webinar recording and slides will be available in a couple of days.

So, I'm going to start off and talk about where we've been, where we think we're going to in the world of CIM. Then Jeff will talk about Ory and some of the use cases, the case studies that they have encountered. And then we're going to do a little chat. We'll take a look at the poll results and take your questions at the end.

So, with regard to poll questions, we thought we'd start off with one. I know I've heard from many organizations that they are still using their own homegrown CIM solution.

So, we're curious where you sit right now. If you have a CIM solution, are you still using homegrown? Are you using a commercial product or service? Or maybe you're using a combination of the two.

So, feel free to answer that when it pops up there, and we will keep going and talk about the results a little later. So, evolution of CIM.

Well, you know, most likely for everyone, it started in your enterprise IAM, you know, which was hosted on-premises. You probably had an LDAP directory. LDAP directory may have been a little too limiting for what you really needed it to do because, you know, maybe the schema wasn't exactly what you expected it to be. You had other attributes you needed to other kinds of data in the database.

So, it may not have been, you know, ideal for what you were trying to do with it with your consumer-facing applications. And, of course, it probably had and still has in many, if not most cases, password-based authentication.

And, you know, if it's on-prem, then that certainly makes it harder to scale, you know, licensing costs, having to deploy more servers, make sure you've got servers in all the right locations if you're in a big enterprise with, you know, you're serving a global customer base. So, every time you needed to expand, you had to buy servers, you had to make sure you had space in your data center.

Then, you know, 15 years ago or so, we started seeing our first cloud-delivered CIM solutions, and they were really designed to be turnkey. You know, they were fairly easy to connect to. They had the notion of being able to accept social network credentials and even use that for authentication. And that's when we started to see more and better kinds of authentication mechanisms accepted, too.

But then, you know, both of these models had some difficulties in organizations that, you know, may have had a lot of developers, you may have had a lot of homegrown applications, and you really just needed to wrap an identity layer around these applications that you're exposing to your end users. That's where, you know, what we would call developer-first or DevOps CIM came into play. And these are really the ones that claim to be, and they are, API-first.

So, you want to access any capability within this type of CIM system. You can generally do it through the APIs. Many of them also provided SDKs, which made it easier for you to build mobile applications that tie into your line of business applications. It's very application-centric, and it's much more ideal for organizations who, you know, have that approach, say, compared to either trying to leverage, you know, an internal IAM system or CIM system, or even some of the early SaaS-based CIM systems.

But where we find ourselves now is our CIM systems, regardless of where they're deployed, need to be able to handle agentic AI. And we see standards that address this today, things like dynamic client registration and pushed authorization requests, to be able to give scoped access to the agents, and to be able to bring a human in the loop when needed.

So, regardless of where you are in your CIM journey, you probably have a lot of these same goals in mind. You might want to get rid of your inefficient CIM solution. You've got to be able to offer self-registration.

You know, maybe you do have big databases full of existing users. You need to migrate those over, but you also need to offer self-registration, increasingly things like not only social network logins, but decentralized identities. You'll need to host your consumer profile somewhere.

And again, that might include different types of data than what, you know, might fit into an enterprise IAM system. One of the goals for sure is converting unknown users into known customers, you know, getting past the guest checkout stage, and then collecting consent.

You know, different places around the world, including multiple privacy regulations in the different U.S. states, many of them have this requirement to collect consent from users about the data that you are getting from them and storing, and then what you can do with it.

So, consent collection is really important. Authorized collection of consumer data for the purpose of being able to do marketing analytics, marketing automation. It's about personalizing what you may offer to a customer with the big end goal of increasing your revenue. Improving the user experience can also include better and stronger authentication mechanisms and having some ability to prevent fraud. Anything that's attached online these days is prone to fraud.

So, if you can do, let's say, passwordless authentication, that's certainly one way of helping prevent account takeover fraud, for example. And then, lastly, collecting identity analytics for security. In case you do have to do an investigation, all this information needs to be collected, logged, so that you can support, let's say, forensics exams later on.

So, what are some of the things that have gone wrong in past CIM deployments? Well, it can be difficult to deploy if you've got to procure space and servers and things like that. Just that in itself can be a difficult thing to overcome. A lot of the early gen CIM solutions, like I said, really didn't expose all the features through API.

Now, a lot of the platforms that you see available out there are completely open via API, so that maybe you don't even want to use the management console, but you want to be able to integrate controlling the CIM environment from another application. That is possible, so long as there's sufficient API availability. Integrating with legacy apps has always been difficult.

I mean, I think we still see lots of places where, like, a reverse proxy architecture is used. Standard support can help overcome that. If your back-end applications can understand some of the more common identity protocols, that certainly can help there. The identity and marketing analytics, CIM actually, too, kind of became a silo.

You know, it was difficult to share information out of it in the olden days. Now, openness, not only through APIs, is just sort of expected, you know, to be able to share information, let's say, between your CIM system, your customer relationship management systems, your customer data platforms. Openness is the key to getting the maximum value out of your CIM solution. Scalability, we mentioned. Weak authentication only, we mentioned. Consent collection was often insufficient. We've seen the development of many third-party consent and preference management platforms.

A lot of CIM solutions that, let's say, may not have fully implemented strong consent management may have connectors for these third-party consent and preference management systems. So, without that consent management, it can be difficult to comply with regulations. That's one thing we always like to encourage people to do when you're looking for a CIM solution, figure out which jurisdictions they operate best in. Do they have coverage for things like GDPR, CCPA, PIPEDA? There's a number of different ones.

Depending on where your business or your organization operates, you'll want to look for a solution that can help you comply with the local regulations. And then, lastly here, licensing subscription costs. It can be expensive to deploy lots of servers. There are lots of different ways the SAS-delivered CIM solution providers might charge for their services, but typically things like monthly active users with perhaps some additional transaction fees for like identity verification events, that's a pretty common way of doing the licensing and subscription.

I thought we'd look at our Identity Fabrics framework here for a minute. I know this is a lot of information on the screen all at one time, but we'll just kind of walk you through the concept quickly here. On the left, you see the different types of identities. Everything from like your enterprise workforce users, contractors, business partners, business customers, and consumers make up the different types of human identities that we encounter. But then we also see an increasing number of NHIs or non-human identities.

This could be anything from a workload to IoT devices, and now, of course, AI agents. And you see a lot of statistics that indicate there are maybe 50 to 100 times more NHIs in typical user databases than just regular human identities. Moving into the center here, in order to be able to serve all these different kinds of identities, we need different capabilities. Everything from administration, things like identity verification, authentication, authorization, and then integration.

You know, no security tool is an island unto itself. You need to be able to export that information to things like SIEM solutions, so you need support for Syslog or CEF. You probably want to be able to connect it to your ITSM, so you can create packaged into various services. A service could be anything such as an authentication service, an authorization service, identity governance services.

And then these tools then are packaged into, or these services are packaged into tools that we consume, like IGA or CIAM, Privileged Access Management, with the goal of being able to help secure target systems on the applications, devices, your line of business applications, and so forth. I think the main takeaway here is that the identity fabric is composed of many different threads.

You could follow a thread of CIAM all the way from left to right, you know, identifying things like customer users, consumer users, what services and capabilities that they need in your particular enterprise, and then that can help you with tools choice on the other end here. So how do you evolve your CIAM solution? Let's say you've got, you know that you need to be able to offer things like better authentication, or you need better consent management because you are operating in environments where you have strict privacy laws you've got to adhere to.

Well, I think we all know it's practically impossible to just do a rip and replace. I mean, I think some studies have shown that it can take upwards of 10 years to take a full CIAM suite and migrate it.

I mean, it can even be difficult just to do an in-place upgrade. So how do you keep up with, you know, business trends and things that your business leaders are asking for? Do it in specific pieces. Going back to the identity fabrics model, look at, okay, I need to upgrade authentication. I want to use an authentication service. Can I find a way to, you know, contract with an authentication service provider, still use the IAM solution that I've got, but bring better services to my users, all different types of users that you may have to serve.

And again, I think if we adhere to standards and following on the authentication use case, you know, FIDO, pass keys, definitely something that many, many vendors, both full CIAM solutions as well as specific authentication service providers offer, and they follow the standards. So if you can adhere to standards yourself in your own organization and then leverage third-party products to do this, it should make it easier to more modularly upgrade your CIAM environment. Some of the trends that we see, you know, MFA options have been around for a long time. Strong authentication is possible.

Passwordless is definitely possible. We know that surveys show that users would prefer passwordless authentication options, but the truth is they're just not as widespread as we'd like to see that yet. We also see a lot of use of remote onboarding apps. These are the ones that, you know, you take a selfie, you take a picture of your driver's license or passport, or maybe it uses NFC to chip.

These can be very good about decreasing the amount of time and labor it takes to create accounts, but with the advent of AI, particularly around image generation or audio video generation, this has created a huge spike in deepfakes, and that's something that is leading to more and more presentation attacks or enrollment time attacks. These are things that we have to be on the provide solutions that can detect deepfakes. We mentioned NHI management. This is growing. It's only going to keep growing. B2B CIAM use cases are on the rise.

The last few times I've done the CIAM leadership compass, all the vendors indicate this is one of the areas of largest amount of growth within the CIAM market. Agentic AI is here.

You know, not only do we have agents and browsers, now we have AI agents that are effectively acting as browsers, and, you know, this situation is only going to get more complicated, and I think, again, for IAM professionals, this is what this can make it more difficult because how do you distinguish between a human and an agent that's operating on behalf of the human? How do you do access control? How do you say, you know, in the most common use case that everybody talks about, you know, with a travel agent acting on behalf of you, how do you set limits? How do you enforce those limits?

How do you get a human in the loop decision when you want one? And then lastly here, we know that there are lots of good products out there on the market, but, you know, our own experiences probably show us that most of the companies that are are really not making the most of the capabilities that they have, which, in the long run, really leads to, you know, fewer sales, maybe fewer customers.

So, I think it's in all of our best interest to take advantage of the CIAM capabilities that are in the solutions that we're using today. So, wrapping up my part here, you know, it's, I'll admit, getting digital identity right can be difficult. A lot of it has to do with how we interact with our business leaders and figuring out what are the objectives that the businesses have.

You know, as CIAM professionals, we work in business, we may not fully understand all the things the business is trying to accomplish, and oftentimes they don't understand the technical details that we do, but we have to find a way to work together. Moving forward, you know, I think a lot of companies or organizations have built, or at least have had their business processes affected by the architecture of the CIAM and IAM systems that they've put into place.

So, let's say you're facing an opportunity where you can upgrade, maybe not your whole CIAM stack, but individual parts of it, it's a good time to think about what can we do, how can we design our CIAM processes around what we know the business really needs, how can we make it more efficient by utilizing the capabilities that are here, might be a good time to break away from the traditional way that we've done things and leverage the capabilities that are there. So, with that, I'd like to turn it over to Jeff.

Excellent, John, thank you. Great background, a lot of really good information in there around, you know, why I think the last slide really summed it up quite well, right, why digital identity is hard on that side, and it's a problem and a challenge that we see. I think we're gonna do a quick little poll question here and then we'll hop into it, if I'm not mistaken, just around your top concern around scalability.

I think this is an interesting question, we kind of focused it on, you know, some key areas that we see in identity, but just in general, scalability seems to be a concern for a lot of organizations. So, if you would respond to that, we would appreciate it, then we'll go over these results as we go to the last section here.

All right, moving on here, so, you know, Ori agrees with a lot of what John stated here, you know, we all know that CIAM needs to be better, and it's not an argument necessarily of, hey, let's always make better technology and new ways to authenticate, but those are always welcome.

Really, a lot of this just has to do with the same problems that are really hard to solve, and we've been trying to solve them for years, and sometimes it's, you know, yes, there are technology limitations, sometimes it's the way that the business is being done, right, from just how you have to serve your customers, but a lot of times it's just the complexities of the way the world works, and so, Ori definitely sees a lot of those same things and how things need to move forward, but one of the big things that we've noticed with our customers is really twofold around CIAM.

One is that it needs to be a growth vehicle for them. It needs to enable the business to increase, whether it's reach in the case of publishers or customers in the case of, you know, a retail site or something along those lines, and that presents a really unique and specific set of challenges.

So, let's talk a little bit about two use cases here around kind of some unique needs when we're scaling and how CIAM can be used to achieve some really cool goals around enabling growth, and we're going to start off with the first one here of OpenAI. I'm sure that's maybe why a number of people joined this call is to hear kind of what OpenAI did, but we're going to dive into it and kind of look at what they did to help them achieve the growth.

Now, I'm not going to say, if we want to go to the next slide here, I'm not going to say that OpenAI's growth was enabled entirely by identity. I think that would be a very bold statement.

However, what I do think is interesting to point out with that, and many of you may have experienced this previously, is that whenever OpenAI releases a new model or new function or feature, there is a rush to go log in to chat or whatever interface or use an operator agent to test it out, and one of the things I remember, quite a number, probably about three years, two and a half years ago, was in the early days of going to do that and then not being able to log in or there being authentication errors or rate limits or things along those lines around getting to the actual experience, and that was frustrating as a consumer, and I think OpenAI definitely recognized that, hey, you need to have a resilient identity solution that's robust enough from a scalability standpoint to be able to allow people to log in regardless of what's happening.

They really needed that web scale authentication and access on that side, and so that's something that they looked for in modernizing their science solution, and they were kind of a hybrid approach.

Some stuff was off with a vendor, other stuff was homegrown, and they've kept that approach moving forward, but they've moved more and more bringing things in-house for them, and the reason for that is that they also wanted the flexibility to deploy just the pieces that they need where they need them, not just send everything off to a vendor and kind of see how things happen and get the result and move on from there. They wanted the flexibility.

They wanted to also be able to observe what's actually happening during authentication, right, so that they can see where the bottlenecks are and they can look for alternatives and different ways to handle it, things like having a clear idea of why maybe refresh tokens are bouncing rather than refreshing. What's happening there? What do we need to do? Can we tune some things differently? Is there some client-side bugs we have?

So those were really important to them, but really what it was about was unlocking that ability for consumers to still, no matter what, authenticate and assist to the platform, and there could be other things downstream from that that may limit some access, right, like sometimes models just get throttled, especially if you're on the free plan, like I think we've all been there, right, where we realize we're not signed in maybe or we're on a new device, and then we ask a couple questions and we get throttled, but that doesn't have anything to do with the authentication, right?

The authentication is no longer deployed, which is huge, and so they've turned that in a way to continue to grow because now they're not as worried about what's going to happen when we release a new model, what's going to happen when we release a new feature set. On the flip side of this, if we go to the next slide here, we can also talk about a media publisher in the same type of way. I think we went one too many here. Here we go. They had a lot of challenges that were strangely similar to OpenAI in some regards.

Now, they aren't releasing AI models that people are going to interact with, but they are also breaking really big news stories, and this is for Asher Springer, where occasionally events happen in the world and a news story goes out, people run to one of their properties to go look and find the information, or sometimes there's a special event, maybe a sporting event or something like that, that people are going to.

So there's these periods of extreme peak scalability that they needed to handle, and they had a homegrown solution that was really kind of driven towards handling that initially, and they realized that, well, the homegrown solution gave them a lot of flexibility.

It also limited them because then it was on them to handle the scale and build the solution on that side, and so they wanted to partner with someone who had the expertise and the kind of standards know-how to help them rebuild their identity system around a lot of the standards on that side, and for them, that scale was super important.

Being able to burst authentication traffic for needed different events was something that was really, really impressive and helpful for them, and one of the big things that they actually found during their rollout is working with a vendor that is with an identity vendor, and I think this goes across the entire industry.

One of the huge advantages that you get is that you get this ability to kind of use the company's knowledge around things, and usually it's, you know, the identity company coming in with something like past keys or adaptive authentication or these other features, and they say, hey, look at this great thing, and then the company goes, oh, yeah, we can see how we could use that, and they fit it in. This one was interesting because Actual Springer actually came to us and said, hey, are you guys aware of this standard called FedCM? We were aware of it.

We hadn't seen a whole lot of customer demand for it, but they said, hey, we'd be really interested in partnering with you to get this out in your product and see how this can impact our user authentication, and they actually had a huge 10X initial uptick of authenticated and registered users when we enabled FedCM, and for those who don't know, FedCM is a really neat feature that it uses the same browser protocol that past keys do, the navigator credential protocol, and it actually allows the browser to handle the social kind of login that you're used to through the browser directly, not through the actual webpage, and so what that does is it moves the trust model out of, like, third-party cookies, right, for handling social login and puts it entirely in the browser, and it's a really secure channel for social login.

What it means is because it's kind of not necessarily invisible but kind of really built into the browser experience where you might just get a little pop-up that says, do you want to continue with your Google account or, you know, your Facebook account or whatever it is, users are more likely to engage with it, and so they saw a huge initial uptick in users registering that way, and then also they're seeing this massive increase in just page hits where it's now a registered user, and for their business, that's huge of knowing who the user is who's interacting with the page allows them to tailor different parts of their business for that user and also tailor recommendations and things like that for deeper engagement, so that was a great synergy where they needed an identity system to handle the scale, right, but then also being able to partner with some of the standards to implement those for them as well.

So a little bit about Ori. I'm not going to spend a whole little bunch of time on this, but just for those who don't know, if we want to go to the next slide, the main reason why people choose us is because, one, we're modern science. We're built across, you know, kind of more of the modern technology stack. It's not a kind of a large monolithic black box solution. It's actually made up of five open source solutions under the hood, which we'll talk about a little bit later, and it provides a lot of flexibility to customers.

They can pick and choose which parts they want to deploy, so earlier John talked about, you know, that flexibility to not rip and replace but just kind of add on pieces. That's something that Ori's really good at. Maybe it's just that you need a really good machine-to-machine tokenization layer.

Great, Hydro. That's something awesome that Ori can do really easily for you. Maybe you're just exploring the AI world and you want to handle permission guardrails and things along those lines, and Quito is something that we've built around fine-grained authorization based on Zansbar that can handle that. We also think it's extremely important to have observability be a first-class tenet of your product, so we build a transparency to everything that we do.

I mean, one, because we're built on open source software, you can go out there and look at the code, figure out what's happening under the hood, and just see the core of everything that's going on there, but we've also built telemetry and things like open telemetry into the product at every stage, so you can see exactly what's happening and have a clear understanding of how that user's authenticating or what actions they're taking, and then I think in today's world, you need to handle scale, and this will kind of be my segue a little bit to a bigger and bigger problem for people, and on the surface, it looks pretty straightforward, but what I think is going to happen is that we're already seeing bot traffic, both good and bad bot traffic outstripe human traffic on the web, and it's not that human traffic has decreased, to be clear, it's just that bot traffic has exploded, right?

There's so much more activity, whether it's LLMs just scraping data or doing web search through tool extensions or even MCP servers that are now exposing more, or AI agents that are going out there and gathering more information, we've now taken something that was a human interaction, just like one time logging into a website, one hit there, one browser, and we've now multiplied them in some cases by five, if not 10, for a user who's in their, you know, kind of plot or AI interface, asking it to go do some research for it, it's now spawning a bunch of threads and doing all those things, which in some cases have to be authenticated, and I question whether a lot of systems will be able to handle that scale.

So let's talk a little bit about this AI shift with identity, because I think it's important, and I think it's top of a lot of people's minds. I kind of like to harken this back to like the smartphone shift, and I think I've heard a couple people talk about this a little bit, but when smartphones came out, it brought basically identity, it brought information into your pocket, like a library into your pocket, right?

You could go look up anything on your phone, and I think a lot of companies realize that, hey, if we're not on the user's phone anymore, right, if we're not on like the home page, if we don't have an app in there, you're really losing a lot of engage, and you're honestly kind of losing out in that battle in the smartphone era.

We saw this huge shift, and heck, this shift still happens, right, of everyone moving mobile, right, because that's the way people are interfacing now, on tablets, on mobile devices, they're not using computers as much, there was a little shift back, I think, if you look at the numbers, but for the most part, most casual users of technology use on the mobile device, and what's interesting about AI, and specifically agentic AI, is it's kind of doing almost the same thing, but rather than, you know, just bringing the information to, you know, your device in your pocket, it's now bringing kind of that intelligence through conversation, right, so it's no longer just like, hey, you can go look up data, it's now informing you actively through conversation, and something that I think is really interesting, and a unique parallel to the smartphone era, is that, you know, companies early on realized with smartphones, hey, we got to build apps, right, with AI, one of the things that I'm curious about, and I see a lot of, is if you're not involved in the AI agentic world, or just with LLMs, what is the AI saying about you, right, and I don't even mean on a personal level, I mean, like, as a company, what does the AI say about you, you know, there's a lot of work going into things like llm.txts running on your site, so like, full information for the LLMs, to talk about you, exposing different prompt information through MCPs, but if you're not part of that conversation, it's going to be a lot like the smartphone, right, where if you weren't an app, especially like a social media platform, if you weren't an app on their smartphone, they're not going to use you, right, and it's the same thing with AI, if you're not informing that conversation, how are they going to know about you, what is the LLM saying about you, what are you going to do on that side, and I think a little underlying piece of that, with the identity side of it, is that it's important for you, as a company, to know who the users are interacting with the LLMs, so that you can inform them in the right way, that's context appropriate, as well, because you could be doing a lot of things in the business, but if someone says, hey, what does this company do, and they want to know, what does it do for me, you need that context, and I think that's where identity gets really interesting in the AI world, is how do we pass that context through the entire system, and we're seeing this, if we kind of go to the next slide here, we're seeing this with a lot of our customers, you know, traditionally, if you go look on the left-hand side, we'll build out the slide a little bit here, there's traditional black blocks, IAM, we know that it's rigid, they're opaque, sometimes they don't adapt easily, because you don't have a lot of flexibility and control, sometimes we're forced to kind of fit what is the square peg in the round hole, for whatever solution is on that side, on those pieces, with Ori, we're not that way, we can be self-managed, we can handle scale, as we build out into different parts of this, but really, what I want to focus on here is that, you know, we're at a today pace of 100 logins per second, is kind of the benchmark that we're seeing for a lot of our customers for authentication today, but we're quickly seeing in the AI workloads, that go to thousands of logins per second, and what's interesting about that is, some of it's easy, right, some of it's like, just like token verification, right, for like an AI agent that's running and operating on its own, but there's also this other piece that John and I are going to speak about in a moment here, which is human-in-the-loop, and what human-in-the-loop does, is that also adds another layer of interaction, maybe through having step-up authentication, maybe having the user having to consent to roles or scopes or things along those lines, and all that's still happening and creating additional load, as these AI agents are going out and doing things, so this is something that Ori is really interested in taking a look at, we're solving this challenge for a number of customers with MCP integrations today, as well as some and authentication on that side, and let's keep moving here, we're going to talk a little bit about Ori and what we offer, just for all of you that aren't aware of what Ori is, Ori kind of really has three flavors of what we offer to our customers, there's Ori open source, this is great for you to go out and build and kind of see how things work, if you need an identity solution, because you're building an MVP of your next product, and you just need to put something in there to see how it works, Ori is a great way to get that done, we also offer Ori Enterprise License, which is a fully self-managed, you get to manage it and deploy it, but fully supported by Ori version of our software, this is the same binaries and containers that run on our Ori network, which is our fully managed SaaS stack that you can use as well, but it allows you to self-manage that and deploy that in the way that you need to consume it, it also lets you modularly choose what pieces that you want, and then for those who maybe aren't at that level, or don't have the infrastructure to self-manage, but still want a lot of that flexibility, Ori network is probably a good option for you, it's a fully managed SaaS stack, it's similar to any of the other identities, SaaS systems that you see out there, but it's built on the same core code, there's five products that make up what Ori does, Ori Hydra is I think the best in class, world-leading OOP2 and OIDC server, in fact I would argue it's one of the, it's probably the widely, most widely used OOP server, if you look at some of the telemetry information that we have about who, how that's being used in the billions of transactions that are happening across that platform, Ori Protos handles your identity management, so things like authentication and trait data, who users are, Ori Polis allows you to bridge SAML to OIDC, allows you to build things like directory sync and the ability to handle those B2B use cases you might have, Ori Oath Keepers are really neat reverse proxy that is identity aware, so it can handle cases where you might be passing in something like a JWT or a cookie or something else that has authentication bound to it and you want the proxy to make decisions based off of that section or JWT details rather than path or parameter or something along those lines, Oath Keepers are excellent at handling that and then Ori Quito is a fine-grained authorization system built on the fact that Google's the hands of our white paper, so it's feedback or relationship-based access control which is really flexible to give you things, the ability to do things like role-based access control, so you can build that on top of there and we're also fairly shortly adding support for attributes as well, so you can build some ABAC instead of B1 as well, but a very flexible system that we're seeing a lot of people take a deep look at for things like putting guard rails around their RAG systems for AI, how do you know what permissions, what documents the AI can go and train on, maybe you need a permissions engine that can inform the LLM agent in a machine way of what it can access based on who the user is, so a lot of neat products out there solving a lot of interesting solutions, I think we're going to swap over here now, John and I here to do a little bit of a fireside chat and we're going to talk about some hot button issues out there of just what we're hearing in the industry and a few questions on that side.

Well thanks Jeff, let's take a look at our poll results before we launch into that and the first question was, is your organization primarily using COTS or homegrown CIM solutions and the is roughly 45% commercial, 45% homegrown and about 10% homegrown, 40% hybrid that is. The second question was, what's your top concern regarding scalability and it's split pretty evenly between authentication and handling peak events, that's interesting.

So yeah, I encourage you to enter any questions you've got into the live storm control panel and we will take those as they come up. So in the meantime, I thought we'd just talk in a little bit more detail about some of the themes that we have brought up earlier and you know, given the fact that there aren't many organizations that still have homegrown CIM solutions, how do you do it? What are some of the, let's say best practices that you've encountered in the deployments that Ori has made?

Yeah, I think one of the interesting things with migrating from even a hybrid solution or homegrown solution or you're adding on or things along those lines, I think one of the first stops is to really understand how your users are authenticating. And what I mean by that is, you might be offering a lot of authentication options to your users, but really what are they actually, what are the common paths? Like how are they actually going about those authentications? Like what are your hot spots, if you will, for that?

Do you have a large contingent of Casky users or are most people still using maybe, I don't know, an SMS OTP, right, to verify their authentication? Are a lot of using social sign-on providers? And I think once you understand some of those flows, that can start then to inform your strategy of how you're going to migrate. For some things like social sign-on, right, like some of that implies if you switch some of the URLs around, then you have to have users be consent, right? Because that third-party process in OAuth requires, or OpenID Connect requires a reconsentive scope, right?

And so maybe you want to think about, hey, maybe we migrate that last, or maybe we migrate that first to get it over with. And maybe we take that opportunity to maybe ask for more from those providers, so maybe they offer more now than when we first set this up, right, and kind of do the natural piece of it.

So flows, understanding how your users flow through your application, and primarily log on and how they do that, I think is really one of the first important things to understand. And then like a quick follow-up to that typically is, what data are you capturing in your existing identity system that you absolutely need and want to preserve? And understanding the shape of that data. There's a lot of times where, you know, just as products have evolved, right, you've collected information that you no longer need, or you're not collecting information that you'd like to have.

And understanding, I think, both how the users authenticate and what that information around the users that you need to do business, or maybe in the future need to do businesses, are really important. Always kind of start with the fact finding first, right? Like if you don't know the facts, like it's hard to migrate up on that side. And that's usually what we go through with customers, is walking them through that.

You know, we're pretty exhaustive in like, hey, what happens in this case? What happens in recovery? What happens in, do you have any like ad hoc verification that happens later on during your product, rather than just at the front door of things? I think that's a really good point.

You know, we do, I'm working on a leadership compass on CIM right now, and I ask a lot of questions. One of them is, you know, trends in authentication preferences that we're seeing out there.

And, you know, I think your point about figuring out what people are doing now, it can be very eye-opening. And just because maybe OTP is popular, doesn't mean it would be as popular if they had better options available.

I mean, I don't think any of us really enjoys OTP, you know, but what's the right next step? Is it past these? Is it using some sort of mobile authenticator?

You know, whatever probably makes it easiest and yet still secure are the options that will gain traction in the years ahead. Yeah, I think that's another good way to look at it too, because sometimes you're modernizing or you're migrating to help for reasons of just like your team can't support, like if you're homegrown, right, like you can't support anymore, or you want to refocus your team on building features that matter to your business, right, rather than authentication and things like that.

Or in some cases, if you're coming from another vendor, maybe something's changed with that vendor relationship. But really like the exciting ones that I get jazzed out of people who also then take that as an opportunity, right?

You know, apples to apples move is good. It's sometimes necessary, maybe the under the hood benefits that will get right offloading of resources to core product, or scalability that you're just getting natively out of the system, all great things, right. But then also taking that to your point, that option, that time to go, hey, if we're already looking at this, like, why don't we, right, why don't we make that an option?

Like, that's a that's a really big thing to look out for. So like, yeah, track your metrics and see what they can about what people prefer. Exactly. So we've mentioned registration a time or two already, you know, and again, the goal is to convert these registrations into customers in most cases, what, what can be done to make this more effective?

I mean, typically, I generally say, you know, progressive profiling, unfortunately, most of the vendor solutions out there offer some degree of progressive profiling. And that's where, you know, maybe at first, all you collect is name, email and password, or, you know, some other credential for authenticating. And then you get more information as needed, but you don't overwhelm the user up front by asking too many questions, which can just send them into a, you know, I'd rather not do this right now. So I'll go find another service provider that doesn't ask you so many questions up front.

What, what experiences have you had with the progressive profiling or, you know, converting unknown users into known customers? Yeah, I mean, this is like the age old challenge, right?

Like, I mean, what's the friction that's appropriate? You know, and I think it, you know, obviously varies greatly by, by, by one, the business that you're in and to the regulation that controls that business, right? If you're a financial institution, you have to provide KYC, laundry checks and all that fun sort of stuff. So your registration process is probably gonna be a little more friction full. I think progressive profiling is great, right? Because then that allows you to put that friction, like deeper in the stack, right?

So that it's maybe, hey, it's easy to sign up for the initial, you know, $500 max limit savings account if you're a financial institution, but to go deeper and actually transact, you need to go through the full KYC AML type of stuff. And once you put the friction, maybe further deeper in the process is a big piece of that. And so I think it depends a lot on your business.

You know, I previously have worked with IDV solutions. So doing identity verification, which I think streamline a lot of the process if they do things like OCR to capture document information to reduce the typing the user has to do, which is a great add-ons to be able to kind of streamline some of that registration.

I think in a lot of cases, though, if your business is open to things like allowing social sign-in piece using a technology like FedCM removes the burden of registration from you completely, and still lets you get all that identity data that you may need through that social provider, right? So if they're already have a Google account, which, you know, verifies email addresses, so that their email verified, great. That's an easy click button. The user's in, they're done. They don't have to do anything else.

If they use an identity provider that doesn't maybe do those steps, you still want to be able to have a system that can at least take that first step of all the initial information, move the user into the, you know, into the registration, and then just maybe have them account. It's the last step ownership, right?

Like, hey, maybe the last step is as much as we don't like it, no TP to email, right? Just to say, hey, like, do you own the email address here? Do you have access to the email box? It's right on that side. For recovery, I'd probably recommend something stronger than just that. But at least for sign-up where it's net new, that might be acceptable on the business side of things. So I agree with you a lot. Like it's a tricky spot to get right. And a lot of it depends on the business.

I mean, I have customers that in some cases, they make their registration process as simple as clicking a link. And it's just capturing the email that they got in their email box, like that invited them to the process anyways, just to start them off. And they progressively profile them like as they go to check out their cart or things along those lines down the road. But the advantages of doing it that way is that you get them in the front door with no friction. And so they can immediately start using your service as long as you're set up for that.

And then you're only putting the right spot like a checkout or a transfer or something along those lines. I think that honestly, I personally like those are the better experiences I've had. It's that I only get that friction at that point.

Yeah, I think customers or consumers have different expectations depending on the type of account and type of business they're transacting with. If I'm opening a bank account, I know that there's going to be some IDV involved and I need to put in more information. But if I'm browsing a site, then for the first few steps, I probably don't want to give any information. If I buy something that I'm willing to give name and address so you can ship me something. So it just depends on the type of business, what the use case is and where you are in the relationship with the consumer. Yeah.

And I definitely think for those who haven't looked at it before, go take a look at FedCM and what it's doing on that site. It's just interesting. It's a way to deal with... It's Google kind of trying to help out a bit with third-party... Help out a bit. But it's trying to help out a bit with third-party cookies just because other browsers have deprecated them like Safari and Firefox and stuff like that. Chrome still kind of has support for them, but they would like to move away from them as well. And it makes the experience...

It's a native experience like pasties, that same type of browser flow that you're used to, just this way it's done for social provider. So it kind of also from a dev load, makes it easier too because it's all following the same stuff. It's not super custom and it's a standard that's backed by all the big orgs out there and with Google driving it primarily. So scalability. This one is interesting because we talked about earlier the difference between doing it all on-prem versus using a cloud delivered service.

Most vendors that have a SaaS delivered CIM solution are using a tier one infrastructure as a service provider. So they have elastic scaling sort of built into that. What are you doing that's different over and above that for scaling your customers?

Yeah, I think one of the big things around scale that we've seen where there's usually kind of the issues start to pop up is especially if you're like multi-region and more specifically multi-geo that have different requirements for data homing and data localization. How do you handle that in a way that's still performant and you can still return the exact same type of service regardless of where the user is, right? So maybe you're a user who falls under EU law for and then you are in the Americas or in Asia Pacific or something like that. How do you have the same experience without compromise?

That is a scale, not just an availability problem, it's also a scalability problem. Your solution has to be scaled like that. So already the way that we're designed as well is we design everything to be as stateless as possible to minimize the need for caching because typically caching, especially in authentication flows, is usually where there's going to be the challenge.

Because what's going to happen is where the user authentication might start, that's where the initial stuff gets cached, and then maybe the user hops somewhere else mid-authentication or you send them a code to their email address or you send them a push notification to their device that takes them a couple moments to get there and maybe a hop change between there. Or what's becoming more common is people use VPNs all the time. I can't tell you how many friends and family I have now that are non-techies that are like, oh yeah, I downloaded this VPN for my phone.

I'm using this now all the time because I heard it was safer. And so there's a lot of that type of interaction that's happening. So you kind of have to look at that side of it from a scalability standpoint. And then I also just think it's just the legacy of how Ori is built from a scalability standpoint. A lot of solutions can scale, but it's like a horizontal or vertical scaling problem where you're throwing more resources at it a lot of times.

A lot of what Ori has done around scalability is making sure that the core component of what we're doing is extremely efficient in the way that the code's working. So a single node can get you on a foot. We have a lot of peak events to our customers today, both on the network and also self-managed where they're able to achieve the same levels of scalability. Obviously self-managed is probably going to give you, if you have the resources, it's going to give you more scalability because you can build it just for your need.

But removing that caching layer from it, using the right database technology behind the scenes as well, super important. And then just designing for things like the proper geo kind of growth and scale that you're going to need is super important on that side.

Of course, everyone has dynamic scaling. Everyone can scale up elastically and stuff like that. But how much you have to scale up and how quickly that time between scale is, is important as well. And I think that's something that Ori does exceptionally well, where there's minimal impact during scale that we've seen. So I want to bring this back for just a minute. Maybe you could talk briefly on where you see the different modules that you have as being threads through this fabric.

Yeah, awesome. I really like this. I think this is a great way to look at identity in general, just because putting everything as one box of here's your identity solution, here you go. There's a lot that can be done with that. There's a lot of vendors who are very successful. A lot of these big vendors, we'll just take Microsoft as an example, who offers a lot of these things through Azure, through Entron, I'll say actually, right on that side. But I think what's interesting too is being able to solve specific pain points with point solutions where your organization needs them.

So from an Ori perspective, we're really strong on B2B and B2C. We do a little bit of B2E for workforce and contractors, but our strengths are really around the B2B and B2C today. We do have customers using us, especially on the open source side for workforce workloads as well, especially machine-to-machine on that side. But those are the two key areas for us. We're great from onboarding. We partner or have the ability to inject proofing through third-party systems to pull out some APIs and things along those lines.

But really around the authentication and authorization piece of it, are some things that Ori can handle well. As we get deeper into things like the additional services, we may not have the direct support for each of these individual services, but we do integrate through webhooks or other tools and technologies to call out to them. For example, we have customers who are calling out to, as they flow through the authentication, the user's registered, they need to update some backend, either database or CRM or something along those lines.

They can pull that information or send that information asynchronously, so they're not having to go make API calls to help sync things on the backend, or they use standards like SCIM to do that and things along those pieces of it. Non-human identities is also an area where we get used quite a bit as well, and more around the authorization layer, the OAuth piece of that.

So we do have, for example, I think it was earlier this year we did a deep amount of work with Canonical around device authorization flow for supporting IoT devices or devices that you're bootstrapping, like in Ubuntu, when you're first loading it up, rather than having to type in your username and password and have a NIC already loaded on your machine or your VM that you're trying to install Ubuntu on.

You can actually just do our code and go through that grant type to help bootstrap and make it easier to log in, which is, there's a human in the loop there, really, the device is what you're offering on the back of it. We see a lot of that. We actually have another customer who very recently went live, and it's in the home automation space, and seen a huge amount of traffic on just machines, just IoT devices, authenticating across the token workload. And I think the bottom one, agents and bots, like the autonomous, that's also a place where we're seeing a lot of traffic pick up.

People just right now today are using OAuth2 as a solution for MCP or H2A and stuff like that, which is great, and I think Hydra plays really well to that piece. Lastly, we do touch a little bit on the role-based stuff around relationship-based. Our system is not tightly coupled to our identity system.

It can be, or it can be used independently. So we do have customers who are just leveraging the keto functionality for very specific end product as well on that side, which is interesting. So real quick here, let's talk about AI agents. I think some of the challenges that we're going to see is that agents don't look the same as users, or at least we need to make sure that there are ways in which they don't look the same so that we can apply the right access controls.

A lot of these attack surface management tools don't really have a sense of identity, so how does incorporating agents into your CIM solution, how's that going to increase your attack surface? And we already know the frauds are using AI, so how do we use AI to help deter some of these attacks?

Yeah, I think that's huge, and it's a bit of an existential problem because I don't think there's anyone who's really solved this entirely. There's been attempts, right, on little things.

Obviously, the WAPs or the big CDNs out there like Cloudflare, Akamai, and things like that, they're doing a lot to help clamp down on some of this. There's some options where they're even going so far as to say, hey, if you're a site that doesn't want LLMs to scrape you unless it's in a trusted way or a way that you can attribute, then you have to have this, right? I think Cloudflare is doing some work around that. That needs to be on that side, which is interesting, but to your point, that doesn't really tell you who the ultimate act on behalf of is for the agent, right?

Who's the actual person behind that? I think that there's going to kind of be two pieces of this.

One, agents are going to have an identity at some point. I don't think really any of the framework's kind of that yet.

I'd say there's agency, which is a board out of Cisco Outreach that's kind of doing some stuff with a directory of agents, right, of known good agents, which will, I think, kind of help because then you'll have a space that you can go to to kind of rely on, hey, this is a list of known good agents or a directory of known good agents, and you can verify that agent's credential, verifiable credential of that agent as well, and then under the hood of that, there's also the human identity piece of it, right, which rides along OAuth 2 today for them, which is a great way to do that, so you get both, right, in that agent interaction.

It's then you go, hey, here's my agent creds, then also here's my human creds, right, on both sides of it, and what that will allow us to do then is hopefully tie back that interaction, right, so that when we're looking at a tax service and we're looking at attacks that are happening, one, obviously, we should be using AI tools to help us get through the news on that. We have to be a little bit careful because I think we've all seen in the past, like, alert fatigue and stuff like that, but it's something that's really interesting on that side as well.

Okay, well, we're almost at the top of the hour here. I did want to mention we've got a new executive view out about Ori, and we'd like to encourage you to take a look at that. In our remaining minute, let's take one question that we've got. How can I make the use case to decision makers that CIM investments drive business growth rather than being seen only as operational costs?

Yeah, that's a tough one. I think a lot of it, like, is going to the different vendors that are out there and looking at their case studies. A lot of vendors will help you kind of make that argument as well internally, right, so we'll provide that information. We'll work with you to make those ROI use cases.

There's real ROI to be found there, and it's usually just sometimes thinking a little bit outside the box, and a lot of times if you have all the numbers in front of you to lay out, you know, like what your current costs are, what your current human capital costs are versus vendor costs, and all that played together is something that we can, a lot of vendors can help. Yeah, I guess my last addition to that is CIM is one of those rare tools in cybersecurity or identity infrastructure that allows you to actually increase revenue.

So if you do it right and you're a business that's trying to generate revenue, the case can fairly easily be made that a good CIM implementation can help you do exactly that. So thanks, Jeff. Thanks for being here today, and thanks everyone for attending. Definitely a great subject, and I'm sure there's plenty more that we could talk about.

Yeah, I can go on for way too long about this, but I appreciate your time, John. Thanks for everyone who listened, and please feel free to both check out the wonderful analysis that we have from Cuffinger Full as well as Ory as well. Really appreciate you guys' time.

Thanks, everyone.