Behind the Scenes of Cross App Access - Okta Developer Podcast

Hello and welcome back to the Octa Developer and Integrator podcast. I'm Emily >> and I'm Jeff >> and today we are joined by special guests Aaron and Matt. Um, welcome to the podcast or welcome back. Um, you want to tell us a bit about yourselves and why you're here today? >> I'll go first. Uh, Matt Egan. Uh, so director of tech strategy. I work in the corporate development organization here at Octa. uh gives me a lot of exposure to everything from uh our uh venture capital arm octa ventures to M&A and strategic partnerships where I end up working on uh integrations with hundreds of ISVs over my uh almost eight years at Octis. So excited to be here and talk about Optane. >> And Erin, I think you have a fancy new job title since we last talked on here. >> Oh, that's a good point. Yeah, identity standards now. Um nice to be here. So I work on a lot of specs for OOTH open connect um couple other things as well and lately been working a lot on the OOTH extension uh that we've been using for cross app access and uh going to hear about that a lot at Octane I think so looking forward to the to the discussion today. >> Yeah it's really interesting I work a lot with Matt and Aaron in my day-to-day so thank you guys for being on the podcast. Yeah. So we have briefly explained cross app access uh in the past. What I personally as an enduser think of as the problem that we're solving is asking end users to consent to sharing their employer or their organization's data with some third party service. it's bad user experience and do we really want to be trusting everyone to be a security professional in every organization or can we make this better as we have more and more applications that need to integrate with one another and now especially as we have AI agents that we need to integrate in appropriate ways and share the right data but not the wrong data with them on the user's behalf. >> Yeah, it's a it's a really interesting problem. There's I guess like two main angles to it. One is the one you mentioned of like is it really the user's business the employees business to decide whether a company's application get can share data with another company's application? No, not really. But like from a personal ooth perspective absolutely right like I need to make sure that I choose whether my Google data is shared with a third party application but that doesn't really translate in the employee employer scenario. So it really should be the decision of the company to decide which applications share data just like it's the decision of the company of which applications to use in the first place that get configured for a single sign on. So it's just that there hasn't been a way to manage that with any specs prior to what we've been working on here. >> Yeah, I think that's a great point. It's uh there's been some interesting discussions come up as I've seen other people talking about cross app access and uh had a LinkedIn thread that that started where there was there was some I don't know I'd say consternation about you know the idea of removing that consent dialogue. Um and I think it's it's actually a more appropriate uh what codification of of who actually owns the data and who should be giving that informed consent. Think about what's what's the informed consent for an employee in that relationship. And it really moves more into like have I gone through have I accepted the uh terms of use within you know within the employee you know manual am I uh trained in the you know in the LMS have I gone through the the data handling requirements like that's the the employees responsibility and so cross access kind of gives us introduces an opportunity I'm not saying we're solving that problem today but it introduces this opportunity for the IDP to be in the middle and broker a number of those things and you know I I envision a future where potentially we're are plugging into the learning management system and that becomes a part of you know what that flow could be you know optionally in a in a in a company thing but there's a really important step to to just even opening the door for something like that something that's uh I don't even know how you begin to to to really do that today in the absence of cross app access >> well it's interesting too that uh LMS's have actually attempted to solve this and you see this a lot with the iteration of ways to build interconnected apps on behalf of people um a couple of like thoughts that I have just historically that one we we left this remnant of B TOC moving into these interconnected apps like for so long into the enterprise like it makes sense to us like I think what's interesting the interesting microcosm is I'm really confident if you're saying like I need to share like my documents and my information data I'm really all about making sure I have that consent as an employee I lose a lot of that confidence because like am am I doing the right thing and also like who's at risk if they know that I'm the one that granted that access is Is it me that has to face the consequences or are they actually going to look at the application that kind of like got me there? But I don't know because the application is not really a thing but I've actually got a real job and so so but anyway getting back to the LMS's like this is more machine focused like how can I put the two machines together and transfer that data and so the user kind of gets lost in that shuffle as well and what I like about where we're evolving to is uh a state where like there's there's actually like equal footing between the machine caller and the user that needs to have this consent and we're also like binding that with the visibility and control of the IDP. So, feels like natural evolution, kind of like a Darwinian kind of thing, but not to take away from Aaron's innovation because seeing all of these pieces that need to be put together, it was really like very novel how he was able to to construct this draft, but it makes a ton of sense and actually that's what we hear from ISVS and customers. Erin, could you tell us a bit about putting that draft together and how you were able to find the right point in this incredibly complex system of standards to make this particular change to solve this particular problem? >> Yeah. Well, I mean, I I can't take all the credit for sure. Um, this really kicked off with Carl McInness, who is a is is a co-author of the the OOTH draft with me. um back when he was at Octa uh saw this problem and saw this problem of you know admin visibil visibility of the OOTH grants between applications not being there and put that in front of me and said like you know we've got this problem like here's a rough outline of how I think we should solve it and I kind of just like sat on that for a while and just let it sink in and started working on different ways we could take building blocks that are in the OOTH ecosystem and make it work. We went through several iterations of the actual mechanisms of how to do it uh before landing on what we currently have. And a lot of what I was doing in that process was uh rewriting it to to use more of the existing and standard building blocks that already exist. So for example, the the first step step had always been the idea of using a a token exchange to exchange an ID token for something and uh but token exchange is a is a framework and it's extensible and the first version of it was far more custom. there was like more custom things and more things that you had to add to the request and response and it was basically um token exchange was just you could just barely see that through the spec. So I I spent some time working on like how can we trim it down and make it work more closely like the token exchange spec and then how can we use uh something for the the second leg? how can we take find something that's already there and use that for the second leg as opposed to using, you know, making something up custom for that or whatever. So, um, it was a lot of like because I've been in the OAT space for so long, I've I'm pretty familiar with a lot of the RFC's, at least at a high level, if not into the weeds of all of them. But just having that like broad knowledge of what all is out there and how people use things, I was able to kind of put it together in a way that was uh what what I hope feels natural. >> Yeah, it sounds like a fascinating editorial process of almost looking at each component and going, can we use something close enough for this to save people from having to rebuild something? Matt, are you able to share about the feedback that we've gotten on it from the integrators and the businesses who have had a chance to play around with it and see what it can do? >> It's really interesting. You you jump into a lot of these conversations and as we lay out the problem oftentimes we'll get into these conversations and you'll you'll end up hearing the ISVS. Uh I remember specifically I think it was it was box that ultimately said we had a spec we were we've just been waiting for you to build this. You know we we've been saying you know why hasn't built this yet? Uh is something that we've heard at least you know once or twice. So, you know, the the the general thing uh that we find is especially with with ISVS that have a large ecosystem of OOTH apps. So, Box, Zoom, Slack come to mind. They get it right off. They've been dealing with the burden of enduser consent flows that are that everybody's familiar with. If you're if you're a Slack user like we are, we love Slack. Um and it's it doesn't feel like a problem. Uh but you do end up going through that when you when you think about the the scale of I have thousands of employees and we have hundreds of apps and we want them all to be you know connecting you end up with consent fatigue where from an IT perspective you really would just like everybody to jump in and have Slack and have it automatically be connected to all of the data sources that have been that have been uh configured so that everybody has a a consistent user experience. So people that have been in the space for a little longer um they click faster. I will say the the more nent companies uh you know the the hot open AIs of the world they understand what we're trying to solve but they haven't felt the pain as as acutely yet um you know so so it's on the spectrum of you know how much pain have people incurred and how quickly are they trying to move but in general I would say the consensus everybody agrees with the problem statement and uh you know now we're just in this interlock of it is a three-party problem and so everybody's waiting for a first mover and and uh so we expect to see a pretty quick adoption curve. >> The one thing that um does people get people's eyes to light up is this idea that especially in these tools that are that are AI tools, but also in the the kind of platform integration platform tools like workflow automation stuff where you have someone wanting to use an interface to connect data from multiple different places. So, a lot of the AI use cases are obviously that. Um the thing that really gets people to be like, "Oh yeah, this is gonna be a problem." is the realization that like if you want to connect this tool to 20 different data sources in the company, each person at the company would have to go through and connect the tool and go through an ooth flow and sign into the IDP and then do it again for the second one. Go do an OOTH flow, sign into the IDP again, and doing that 20 times before they can even start building the thing they're trying to do, right? And it's not a good user experience. And it's also on top of the, you know, admin visibility problem of the admins not being able to see those connections. So that kind of like amplification of the friction of an ooth flow is what really gets people to be like, "Oh yeah, that makes sense. I get it. I can see that's going to be a problem." And it's just that some people haven't had the time in the market with the companies at that scale where they're hearing the complaints yet. But it's very clear to see that that is like that train is headed right for them. >> Yeah, agree. I I think one of the other, you know, interesting points to draw out is in the absence of this, you can tell when somebody's been considering an alternative option. And the alternative options are usually like, well, let's just use a service account and go and scrape all of the data, you need to inherit all of the ACL's and enforce all of the ACLs and and that's a lot of liability for an integrator to carry. It's going to be friction when you're trying to onboard those apps because now you've got to bring it in. there's going to be larger security reviews. That's that's been a you know a nice thing. You see the light bulbs turn on when people realize oh I can abandon you know that uh you know that pursuit that was just going to open up another can of worms down the road. So it's not very often that you're able to go in and say hey we're going to improve the security outcomes and the end user experience and that's a you know it's kind of like a a bang bang. It's not often that you get to do both. When you say scrape all of the data from something, even if it's a small amount of data, let's say per user, you scale that and suddenly your storage costs start looking scary as well. >> There's the storage cost, but having to um arbitrate that data access is like handling nuclear waste material. It's it's just a liability that nobody wants to take on. >> Yeah. There's like the giant situation of the risk and then the footnote of the dollar signs. And if you can see the risk, then it's obvious. But even if you can't see the risk, they're still the dollar signs. >> Yep. I'm laughing here because I think it's a good example of like how Matt and Aaron and I are sharing a brain on this because I was going to ask like what what do you guys feel is that aha moment and like those are exactly the two that I see. I'm seeing more of like the architecture of like what an agent might look like. So getting like how am I going to store all of this stuff and we push again to the side like similar to what we've done with our end user consent. We're like we'll worry about the identity security a little bit later. And when you actually start to talk about the scale questions, suddenly the things like governance and management and all of the other like key capabilities to keep the uh access for these agents safe comes like rushing to the forefront. Um, and so yeah, like I mean it's it's very rare that you find something that really balances like making just an overall security posture improvement but as well as like improving the lives of like an admin in the case of having to create multiple highprivileged accounts and manage all of those across many different domains or the end user or having to answer consents for many different scopes across many different domains. When Matt was mentioning uh consent fatigue, I was also thinking about the fish risk of what happens when the user is trained that when you're asked to share your data, you just always have to hit yes. That's just what you do. >> The hackers are have been getting creative, right? Like we've solved a lot of the hacks that used to take place. Password reuse still happens. Yes. But like it's a relatively rare actual attack now because we've got multiffactor off, we've got pass keys, like all these things have stopped a lot of the older hacks. So the attackers have been getting creative and having to find new ways to break in. And I feel like the two main categories that are still that are happening now are token theft. Um that happens still a lot even though there are some reasonably good standard solutions to the problem. um just not as widely deployed yet clearly. But the other one interestingly is OOTH fishing and it's exactly that problem of there is no protocol flaw at all. There is a legitimate OOTH client doing a legitimate OOTH flow to a real server with a real user account. It's just that the user got tricked into allowing that application to connect. And uh that is still a pretty big problem and you will find examples written up in major tech press all the time about it. And this is cross access is one of the answers to this problem because it removes the possibility for the user to accidentally agree to the ooth grant >> and if you've just removed that from the from the process you've removed the opportunity to do fishing to do do the fishing attack. So it's I think it's really important >> when you mentioned token theft as well. Crossap access gets us on to shorter lived credentials than the traditional tokens. So tell us a bit about those changes. >> I want to be clear that token theft is absolutely still possible with cross app access unless you also do token binding through deep or something right like crossap access by itself does not solve token theft because at the end of cross app access the result is the application has an access token for another application just like if it had been issued through a regular ooth grant. So, it doesn't change anything after the token's issued compared to the normal OOTH flow. Um, you can layer on DOP onto that just like you can with a regular OOTH flow. DOP being a way to bind the token so that if the token is stolen, it can't be used because the private key wouldn't have been able to be stolen because in the same way the token was stolen. Um, so you can still layer those on. Um but your point about lending itself more to shorterlive tokens is absolutely correct because in traditional OOTH the user is the one involved in the issuing of the access token which means it's just going to naturally happen that applications want to involve the user as little as possible because of the friction. So they will try to get very long live tokens. Like if you think about like you're trying to connect one application some application to read your calendar data and like constantly sync the data that application is going to want extremely longived access to your calendar because otherwise it's going to stop working until the next time you like re reauthorize it and that just lends itself to long live tokens and long live grants. Uh so instead with cross app access the tokens that are issued can be very short-lived because there's always an opportunity for the application to go get a new token without bothering the user again right so like we can because it's all behind the scenes and we've removed the user interaction we can do that kind of thing >> there's a few other interesting points to draw out on that one a bit of call back you know Erin was talking about the oath fishing that that happens in there and that's a depending on the maturity again of like the oath ecosystem you take you know box and Google they've got quite a few oath controls that are put in place and the opportunity for administrators to go in and um allow list specific client ids to to to be used. But that level of maturity is not consistent throughout the ecosystem. And so this again is like the the challenge is either for every ISV to introduce a very mature OOTH uh policy layer or just inherit the policy layer that comes from the IDP. So like there's there's that good thing. The other one that that that I think goes along with this, you know, reducing the the token theft, these post authentication breaches that are going that are going to take place. And that's the direction everybody went as soon as we started putting in, you know, fishing resistant authenticators and MFA. It was like, well, let's not attack the login process. Let's just go get the resulting tokens that that land afterwards. Um, that becomes like a there's a secondary control element to that. And, you know, again, consequence of like the IDP not being in the flow. you end up with a disparit, you know, the following the breadcrumbs of where these tokens have been issued and where they exist um is very diffuse when it when it doesn't go through cross access. And so the administrators are, you know, they just they have to take on more burden to go in and put those secondary compensating controls that are going to be in there. This is not a this is not a silver bullet. Um but it is a meaningful step forward that does allow for a lot more consolidated u you know breadcrumbs to exist. So that from an as you're looking at the secondary controls that are going to go into place, you can go to the IDP, you can see where the tokens are and follow those breadcrumbs from there versus needing to go out to the to the mesh that exists and and hope that you've got the right logs if they even produce them. >> Well, Matt, I think that also doesn't that open up the the gateway to other controls? Like I know Aaron's Aeron's a busy guy. He's got a lot of proposals out there for different extensions. Um I know he's worked um with with certain individuals on global token revocation and like doesn't this give us uh a great way to establish a cleaner contact to remove access like the on behalf access for these like adjacent machines. Now that we're in this interconnected like app world that we're in with AI and everything the user is extended to many different applications and processes that are now operating on its behalf. and that, you know, that lends itself to being able to sever those connections specifically for those. So, you're feeling like this is a good way to start bolstering some of those other things like shared signals and even global token revocation. >> Yeah, I I think the two go hand inand usually. I I I think about what we're doing with cross app access and I've uh it's not branded way off brand, but I think of it as single sign on on steroids. Um, you know, and and something that we realized a few years ago as we launched universal logout and the global token revocation spec to go out there and and give us a way to close the door, right? Single signon is great at getting you in the door, but we don't have a we don't have a really codified way to go close the door. Um, and when we introduce cross app access, you're making more signon events and so yeah, global token revocation or shared signals framework as a as a mechanism to get what a continuous channel of communication between these services becomes huge. You know, today we're using it to to just exchange risk signals primarily from security providers, but the opportunity for that to be a more rich targeted apptoapp back channel communication is is pretty rich or just the the explicit global token revocation. Yeah, the two go hand in hand >> even before um an ISV implements global token revocation. If cross app access is allowing these very shortlived tokens, then you can do some serious damage control simply by not issuing the next token. we get this giant payoff really for the kinds of technologies to get those insights into what's going on with a user such as risk signal sharing. Suddenly there's something we can do with it. >> Yeah, definitely opens the door. I mean it's a within the octa ecosystem, you know, we can we can close the octa session uh but yeah, being able to then go in and say not only are we closing the octa session in response to some of these things, but maybe we'll we'll resend access for those cross app access JAG exchanges to take place. If you can compress the the time window of validity of a access token on a downstream app, that means you're going to get more opportunities for the IDP um you know in that centralized uh policy and perspective to to interdict. >> Yeah, of course it's obviously better to shut that door the moment you realize you need to, but just not leaving it open longer than you have to is still an improvement. >> Small steps. >> Small steps. And the less new code that we have to ask people to write to get things working, the better. Which brings me to a question that I'll bet a lot of listeners are having, which is how much new implementation are we going to be looking at to add cross app access to our integrations. >> Really good question. Remember that there are three parties involved in cross app access, right? There's the IDP like Octa, which is the one responsible for that's where the admin goes to configure the policies of which apps can talk to which and the two app there's two apps. There's the requesting app and the resource app or the app that's trying to get the data from some other application. There is very different amounts of work on both sides of that equation. So if you are building the application, if you're building the API that is trying to be used by some other application in this, the assumption is that you currently use OOTH for your API and that you already have a way for third party developers to register applications and um send users through an OOTH flow and all that stuff and you've already you already issue access tokens which means that you have a token endpoint somewhere and that token endpoint is uh supports the authorization code grant type in OOTH which is as a sort of default OOTH flow. The other assumption is that you also already do single sign on to an enterprise IDP like octa probably through open ID connect. So with those two things in place, the amount of work you have to do to add cross app access is actually very small. It's essentially add a new grant type to your token endpoint and you will see a new token come in that's a JSON web token with this new grant type and you need to validate that token and then decide whether to issue an access token and for what user and all the information about um how to validate the token is in the spec. Uh but essentially it'll be signed by OCTA so you'll know which of your customers it is. It'll have a user ID in it that you should already recognize. It'll have the application that um would have been your third party application and it should actually be a relatively small amount of work to then validate that and then create your own access token like you normally would. Whatever format that's in doesn't matter and issue that down to the application. >> I nearly got that but we had a lot of you in there. So to make it really concrete, let's say that it's our chat app that is going to be as the requesting um party and then octa of course is going to be our identity provider and then our calendar app is going to be our resource server because our chat client wants to show our status of when we're in a meeting on our calendar. The U that needs to have the token endpoint and support SSO that's going to be both the chat app and the calendar, right? >> So I was only talking about the calendar app in that example. So I was talking about if you're building the the the calendar app that has the data that is trying to be accessed. That's the you in in that previous >> then you've got a token endpoint you add your grant type and then you see these requests for tokens come in >> from the chat app. So the chat app is ultimately making the request for the tokens still. It's just that instead of doing an regular ooth redirect blah blah blah sequence, it's done something else. We'll get back to that later. It's done some other stuff and it just shows up at your token endpoint with a JSON web token that was signed by Octa. >> Oh, so if I'm the calendar, then the chat app just shows up and says, "Hi, I have a token. Octa signed it." You check the signatures. You go, "Well, yes, Octa really does want this connection to happen." And bam, you're connect. >> Exactly. That basically means on the calendar app, there is one step. Token comes in, you you send the token back, you send an access token back. There's no longer redirects or multi-step. It's just one request. >> All we've got to do in order to share resources via crossout access is learn to listen for this new type of request. >> Exactly. Yeah. >> And now if we want to request resources, how's that going to look? >> So that's quite different. So again, we're assuming that in this example, the chat application already does OOTH uh a redirect ooth to the calendar and has an ooth client registered there. Um and this chat app also does single sign on through octa. The difference is that we take advantage of the fact that the user has already signed into the chat app through octa. So as soon as the user signs in the uh chat app has an ID token from octab and that's again baseline today right and you use the ID token to figure out who the user is and which user to sign into the application. Now we're saying take that ID token, go back to Octa and tell Octa I'm the chat app. I'm trying to get access to this user's calendar and where this user is represented by the ID. So here >> exactly. >> So you go back to Octto say hey I'm trying to get access to this user's calendar. >> Please let me do that. And then Octto will go and evaluate all the policies blah blah blah that the admin has configured and decide whether or not to allow this request to happen based on bunch of you know all those factors. Uh and if the request is allowed octa will generate this new JSON web token this new jot um and reply back to that request. that JSON web token represents the fact that for this customer this their admin has configured this app to talk to this app for this user and that's all sort of encapsulated in that JSON web token and then the chat app will take that JSON web token over to the calendar saying hey I want to access this user's calendar octa said it was okay >> and then we'll just repeat that hey octa give me the token for the calendar uh whenever we need to refresh that so octa has so much more knowledge about exactly who's been authorized when >> the so the difference is basically you replace your redirectbased ooth flow with this alternative way to make a request for an access token and the alternative being two post requests right it's a post request to octa and then a post request over to the calendar so I think what's worth calling out there is like in the end user consent flow what's visible to the IDP is in essence probably two single signons like I just know that I've signed into the chat app and the calendar app. That's it. >> This is a really really important thing and like we actually haven't really described that in this conversation yet. >> Without cross app access, >> we want our chat status to show when we're in a meeting on our calendar. We're logged into our chat >> without cross app access. The way it would it works is um the user is signs into the chat app first. So they will do a single sign on flow to octa and octa sees some user trying to sign into the chat app um and then decides whether to send an ID token to the chat app and then they're signed in right um and the policy enforcement at that in that flow is is this user assigned to the chat app right and the answer might be no in which case the request would fail um so user signs into the chat app then the chat app wants access to the calendar so the chat app does an ooth flow to the calendar And that's with the chat apps client ID to the client of the client they've registered at the calendar's oath server which is not octa. Right? So then they start an oath flow to the calendar. The calendar says I don't know who this user is. There's just a user in a browser that shows up. Um so the uh calendar app starts an new single sign on flow to octa. So the user lands in octa. Octa sees oh some user is trying to sign into the calendar. We'll let them in. Uh, and then the calendar says, "Now I know who the user is. Sure, I'll give an access token to the chat app." So, what did octa see in that example? Octa sees user is trying to sign into the calendar. That's it. That octa does not see that the calendar is then going to share the resources by issuing an access token to some other third party application. That's the blind spot. >> And so now you put that all together. So what octa sees effectively now is user logged into both apps but this other added nugget of information that we've made this intent to exchange for that jack token. And so now that gives us this signal that not only is the user logged into both apps but there's an intention of these apps communicating the data between the two on behalf of that user. >> We talk about the blind spot. That's also a very painful experience and a very different experience depending on the resources like the IDP discovery that happens is is inconsistence the enduser experience for that. We've had some people, you know, in some of the conversations are just like, is there anything you can do in the meantime to just make that process more seamless? And it's it's something that's really outside of our control. The implementations on the various service providers and how they do IDP routing and and uh you know that user experience is something that's just way outside of our control with uh lots of validation that it is not fun for anybody involved >> in a world where everyone was using this or even where the consent flow were implemented as a subset of this in hypothetical future implementations. It's so much less code especially on the resource side. There's just so much less logic you have to worry about. That was a very intentional design decision uh of the protocol as well of leveraging as much of the existing infrastructure that you already have, leveraging as much of the you know existing specs and things that so that and making it as easy as possible on the resource side in particular because um there's there's sort of more value gained on the the app that's trying to sign a user in and get access to data because they want the data. So they're going to be more motivated to do work to get the data versus uh the the app the company that's on the API side of like we have an API it already supports OT why why do you need to do us to do anything different? Um so there they're less motivated intrinsically to to do work to support this new feature. So we made that amount of work they have to do as low as possible. >> Matt, you talk to a lot of integrators who are building with this. What typically surprises them the most about cross app access? >> I wouldn't say that we've had any surprises, but there there's numerous questions. I mean, client registration, you know, are we how are how is Octa dealing with uh you know, mapping client IDs for these things and is there a path to to removing some of that burden? Lots of conversations that'll start to trail into like dynamic client registration. Um on the requesting side, lots of conversations around like what should you know should we put a consent flow in front of a user and let them know this is happening or not and and uh you know should we do fallbacks you know should we configure policy that doesn't allow for a traditional u uh code flow grant to go through and you know so most of it is just like exploratory like what are the impacts and implications going to be. I wouldn't say that I've heard any like grand surprises. Um, >> being in the conversations with Matt, um, one thing I'll say about Matt is like he's an engineer at heart. Um, and just hearing all of the gears turning while like with the integrators and with Matt on the call as they're trying to work this all out, like a couple of things like how am I going to know what apps are going to support this? It's this fearless I want to get into the wild, but I want to be safe at the same time. I'll echo what he says is like it's it's a lot about discovery. It's a lot about what are the graceful fallbacks like you know realistically like this is new very radical like simplistic in its design and and and orientation but very like revolutionary in what the impact is going to be so that takes time again it's it's evolutionary it's on scales of time right I love to see the uh integrators and customers kind of lean in like how do I you know how do I get started how do how do I successfully navigate this without creating too many like really distinct lines and that can end up being counterproductive to the adoption. So yeah, I'll echo that, Matt. I it's been a joy like being along the ride to hear like you work through those problems um with with with the integrators live. >> You're getting the kinds of questions where the answer is it depends. So what are we finding that it most frequently depends on for those questions like should we force the adoption of this for this particular use case or um how should we fail over if it's not supported by another app those kinds of things. I think a lot of it is ultimately going to come down to what the end customers want because that's who we're all serving in the end here, right? is like there's at the at at the end of this chain of all these different people involved in these flows, there's someone paying for the service to work a certain way and they probably have requirements or opinions and um ultimately we're going to have to enable some amount of those requirements and opinions that we all agree are an acceptable amount of them. So that's why it depends. >> Yeah, I think that's pretty spot on. you know I I was a customer in the past too and so I'm I'm oftentimes putting myself in that like what would I be expecting it's a little bit you know my knowledge is a little bit stale but there's a lot of you know it depends and and some of that opinion you know there's going to be opinion there's also going to be you know existing frameworks and tools that people have that are going to kind of you know shape and and steer what customers are expecting uh you know this this outcome to be some of this becomes a little bit of like black magic too and you know so I think there's going to be a really interesting curve of uh you know adoption and understanding both from an ISV perspective and and the customer perspective as this as this starts to metriculate through and and uh so yeah nuance is everybody's favorite thing when it when it comes to to making some of these things but we're trying to keep everything on rails and and uh like let's you know are we going to do uh are we going to do um uh downscoping you know and the ability to do additional things a lot of people that are looking forward they see the opportunity you see you know you can see them really just like open up at the idea of like what's possible uh when we do this but we're really just trying to we're trying to land step number one and uh and get more of that feedback. >> One of the reasons why you know I know Aeron's had this repo out that we've developed in the open. I've worked on it, my teams have is again so we can you know get this in the hands. I've I've been a software buyer just just like you've Matt and like my engineering brain goes to like well how would I do this? Like I I think I'm a reasonably you know competent individual. I might be able to like reason out how I would get there. Um and so having that like tactile feel about what does the feature look like? What does it actually mean? Um as a builder um also can articulate the need more clearly. And I think like if you look at um some of the other some of the other standards that are out there like Ipsy is like putting an articulation to the enterprise need so that customers can say yeah I want that. like if you're not selling me that then we don't really have that much to talk about. That's like kind of the simplistic articulation that we need to cultivate. And again, that's also why it's one good to go for an open standard and to develop that out in the open so that again we're doing this all for for the customer needs. It's so that they can help us like lead the charge and drive that demand. As an integrator, depending on whose problems your software solves, you'll probably see a relatively biased set of organizations, especially at first, the people that your integration is like the best fit for. And then when you start looking at branching out, selling to more than just those people who already knew they needed you, then seeing what others customers have asked for from them can be super helpful to just understand those um prospective customers for you. So, are we seeing trends yet in those um enduser customer those identity admin demands and requests and preferences or is it kind of still too soon to say? >> I think I would lean on that. It's it's too soon to stay to say, but um I'm I'm pretty I think we have some good design partners uh and the and the opportunity to to put some templates, you know, to put an opinion out there that that people can uh can tear down is is is kind of what we're expecting to see. But I think we'll we'll put some good examples out and and watch it evolve. >> So, shifting gears a little bit. I know Octane is around the proverbial corner. Uh I wanted to get some ideas from from you two. What is getting you excited? I know there's there's a lot of fanfare about a lot of things happening at at Octane, but what particularly is kind of like on your list or has you peaked in interest of what you're most excited about for the event? definitely excited about crossf access. It has been something that you know I've been working on for a very long time about a little over 18 months I think now. So it's it's very exciting to see this come to like come and be become real. We've been we've had a lot of prototypes and sketches and API calls that we've seen for a long time but seeing it uh seeing it with actual UI and getting it's it's just very exciting for for it to be real. >> I like that. uh I've been in the backseat of the journey, you know, for those 18 months thinking and talking about this. I think Aaron and I got pretty excited, you know, as as the AI adoption became pretty clear that that was going to be the that was going to be the driving force behind this. You know, we we'd had cursory calls before that had really taken fire, you know, 12 months ago with with customers and there was there was interest, but it was it was small and contained and it was really difficult to get anybody to prioritize it. So very very timely that we've seen you know the the uh the opportunity that AI has created in this for it to be something that's on people's roadmap because they recognize uh you know recognize that. So being able to to to see on the on the main stage some of those UI mockups to to make this real for customers to make this more real for ISVS for them to see what those policies are like. I think that's that's another thing you know when you're when you're talking to people and it's you know it's our our mockups and our wireframes and you're talking about the protocols and the ins and outs. I think it's not everybody has all of that what is octa context in there and so you I think the the three of us on those calls like we see it really clearly but but the ISVS have a you know an accluded view of what the IDP's capable of doing in there and so putting that picture out in front of them uh you know it's going to be huge you know so that uh I'm looking forward to our session where we'll have Box and uh Kota Grammarly there to to kind of talk through and uh you know share some of their experiences uh and their opinions on on how that's going to land for them. So, I'm I'm pretty excited for that one. >> So, I'm going to jump in real quick because I don't I I love the modesty, but I could tell you I've been locked in rooms with these two guys working and refining on these pitches. What we're going over like like I I'm proud too like we we've put a lot of our effort in like Aaron leading the charge like for 18 months working on this. Matt and I coming in, you know, relatively late to put some more structure in. Uh this has been like a lot of our you know the adage of blood, sweat and tears going into this and um yeah like you know getting this now like central footing um across the octane is is definitely like been been a labor like a lot of what you guys talked about we've been through change like we lived through the MCP rise and like you know Aaron's working in in that group as well to build the structure around authorization as a whole including crossapp access but Yeah, like that's it's it's very exciting and I'm you know I'm definitely you know very honored to work with with you two and like making bringing this thing to life and like there there is hopefully like a celebration and um rousing acceptance of this um and it is exciting to have you know uh committed partners that are like they see the value alongside of us um and and want this to be a reality uh just as much as we do. Yeah. And a quick plug we've got we'll throw some links in the bottom here. Cross app access is available in our integrator free orgs. So if you go to developer.octa.com sign up, you can turn the self-service EA flag on. We do have example repos. Again, those those links will be down below. You can explore this with a common scenario doing the leak resolution or you can go into a more adventurous state and look at agents working with MCP servers. So choice is yours. Choose your own adventure, all of that great stuff. But please uh you know download and get involved and let us know what you think. >> Thank you so much for joining us on this episode of the podcast and I hope that we will see you at Octane. Remember to sign up for Octane online link below in the description if you haven't already.