 Hi, I'm Aaron Parecki, Senior Security Architect at Octa. This year we launched our first Octane for Developers Experience with an agenda full of developer-focused sessions and hands-on workshops. We also held our first Developer Day at Octane made by developers for developers with relevant and engaging identity sessions, a dedicated community zone, interactive identity adventure game, and one-on-one architecture reviews. You could even code your own badge. This webinar is a collection of highlights from our Developer Keynote and Developer Day sessions to bring you the best of our Octane for Developers experience. You'll see past keys and actions, learn how fine-grained authorization is empowering frictionless collaboration, explore digital credentials, and much more. Thanks for tuning in. You are crucial and decisive contributors to protecting user identity. You don't just enhance functionality, you build the very foundation of trust with every user. You are the ones turning complex business use cases and ambitious ideas into simple clicks to delight your users. And Octa's mission is to help everyone to safely use any technology. And developers like yourself are at the heart of that vision. Your passion and dedication inspires us. Our commitment remains firm to make sure that your experience is always simpler and faster without sacrificing security. And today we are here to showcase our latest investments and show what is it to come. As you know, the authentication journey starts with user login, which is the first step in securing your application. The login box is the symbol of user authentication. The username and password combo has become synonymous with user identity verification. And it's been what we have been using for last three decades. It is about the time we move past it. In this keynote, we will steer into three pivotal categories. Authentication, which is logging in. Authorization, which is controlling the access for people who logged in. And of course developer productivity, which is making it easy for you to bring these capabilities to your applications. So we started with a universal login, making it easy to authenticate users with username and password or using common social identity providers. We made it easy to implement login and sign up forms with custom data to help you tailor your authentication experience. Now let's take things to the next level with the latest authentication and phishing resistant technology. That's why earlier this year we announced that we are starting our journey to 100% password less future. Yes. Not only do our end users hate the hassle that passwords bring, but they're also most common attack vector for bad actors. According to 2023 data breach investigation report by Verizon, 86% of web application breaches involved the use of stolen credentials. Bad actors are adept at using stolen credentials and the personal information they obtain to attack other systems. And over this past year we observed more than 14% of all login attempts were considered to be credential stuffing attempts. On the day with the highest share of credential stuffing traffic, we blocked more than 10 million malicious login attempts in one day. To protect your application and our shared customers, we continue to support making security measurements easier. And this week, PASCII support has come out of our labs environment and is available to everyone. PASCII scan and should replace passwords. They are discoverable and can sync across devices, meaning that an application including your browser can discover if there's a PASCII created for it. So you don't need to get creative, create a new password, clicking on the forgot password link, and of course change your password only to be told that you can't use the same password. The great thing about PASCII is that credentials are backed up in the cloud and sync to your other devices, enabling you to move between your devices smoothly. But what does this mean for developers? When you switch to PASCII, the transition from passwords will be smooth because they are easy to support along with passwords. It will also increase the developer velocity as you don't have to maintain or debug password dependent systems. We take care of the complexity behind PASCII so you can focus on offering a better user experience. You can now enable your users to use sync PASCII's tied to their Apple and Google accounts across multiple devices, providing you seamless experience secured by FIDO, phishing resistant authentication. By removing the need for passwords or shared secrets, attackers cannot intercept them or use stolen credentials. Let's take a look at how authentication with PASCII's looks like. And for that, I would like to pass it over to Carla who's going to give us a demo. Hello everyone and thank you for that insightful introduction for PASCII's. Now I want to tell you about this app that I've been building in my spare time, kind of like a side project. I already use out here at work so I decided to add a universal login box to this app that I called Carla's Journal because I'm that creative. At this point, we have a basic login box where I put my email and I'm also going to put my old and complex password that I just created, which I can't remember as usual. And I cannot tell you how many times this has happened to me. So when I heard about PASCII's, I knew I had to try it right away. Auth0 made it pretty easy for me. All I have to do is go to the management dashboard and then in the authentication side, go to my database connection. Then in the new authentication methods tab, I will see that I have both passwords and PASCII's. And the cool thing is I can have both enabled. So I'm going to go ahead and enable PASCII's just by switching this toggle. Now when I go back to my app and I log in, I see that I have a new button, continue with PASCII. And I can use it once I register a new PASCII for this account. Because I already registered my account with a password, I have to log in with those credentials first. And that's okay because it makes the migration easy. I actually remember the password this time. Once I log in, the page asked me if I want to register a new PASCII. And the cool thing about this PASCII that I'm registering is that it would only work for this domain. No other domain will be able to use this PASCII. This makes my PASCII fishing resistant and guarantees that no one will access my journal by stealing my credentials. It doesn't matter how good you replicate Carla's journal. If the website is not that one, the PASCII won't work. Now that I have created the PASCII, I can use it to authenticate. So here's me another day of trying to journal and I click on log in. And now I see that in the username and email field, I can touch it and I can see that there's already a PASCII suggested for me. I can click that or the continue with PASCII button. And now this is a very cool thing. Because PASCII are discoverable credentials, the browser knows already if and which PASCII I have created for this website. I don't even have to remember if I have an account created or not. The browser prompt me from my touch ID to access this PASCII, which means I'm adding more than one authentication factor in one step. Because I am using something that I have, that's the PASCII, and something that I am, and that's my fingerprint. If you remember earlier talked about seeing PASCII. And in practice, if I want to log in, let's say from my iPhone, I can totally do it by using face recognition. And the cool thing about the PASCII is that you can sync it through a cloud based key chain like Apple's Clio. And that would make my PASCII available in all of the devices that are connected to that same key chain. It honestly, it feels like magic because all I had to do was to switch a toggle and everything was just working. We believe strongly that passwordless authentication is the future. And that's why we are happy to announce that every customer identity cloud offering, including our free tier, will support PASCII's out of the box. We believe that authentication flow should fit your business needs and not the other way. We offer actions as our solution to extend authentication. Ever hit a wall searching for perfect action to fit your unique use case in our marketplace? Well, that's about to change. As we are working on actions navigator with Akta AI, picture this. You just chat with a natural language interface expressing your needs and that's all. The AI dives deep, not only finding your match, but if there is none available, also scripting the foundational code of your custom action out of the box. Let's boost your productivity and help you get back to building your core application. Let's enter the future of coding together with actions navigator. And we have tons to share on the authorization journey too, starting with our FGA product that we previewed last year. And to share more on authorization, I'd like to invite our president of the customer identity cloud, Shivane Ramji. Now let's discuss how you can implement a system where your users, the ones you authenticate it, only see and do what they're supposed to. Let's discuss authorization. Privacy decides what can be shared with whom. Compliance says who can access what and under what conditions. And then we all know sharing facilitates collaboration at work and at play. All of these have three things in common. Authorization connects them together. They all have high risk if done wrong. And this complexity is likely not core to your business. So authorization is the next challenge for the identity industry. And Akta is here to help you solve the authorization problem, much like we did with authentication over the last decade or 15 years. Today, authorization is a focused area for the big platforms. Companies like Airbnb, Carter, Google have all built extensive internal systems to implement authorization. But candidly, authorization is not their core business. But they didn't have solutions. They had large platforms and companies. They had to invest in it. That's why we built Akta Fine Grain Authorization. FGA enables you to define your authorization model and we handle storing and surfacing the data to you when your app needs to make critical authorization decisions. Answering questions like who can do what and what documents can be accessed. OpenFGA is a consistent and global authorization system for determining whether users are authorized to access specific resources. And we design OpenFGA for reliability and low latency at very, very high scale. SDKs for OpenFGA currently supports popular programming languages like JavaScript, Go, .NET, Java, and Python. And we're working incredibly hard to bring more SDKs and tools in the future. Akta FGA is built upon OpenFGA, providing what you expect from a managed service. Akta great environment that can store billions of relationships, blazing fast data replication, and all of it backed by Akta, running this massive production critical distributed system at scale. To enable high availability, Akta FGA deploys across multiple regions, preventing service interruption if a region is not available. It also routes your API requests to the closest region to minimize read latency. FGA starts with basic rules that you can use for your application's entitlement management. And as your company and products grow, you can build more complex authorization models, adding granular sharing permissions, and collaboration capabilities. The industry is moving fast, and we're always moving with it, trying out new things with up-and-coming standards and technologies. One of the things we see a huge potential in are digital, cryptographically verifiable credentials. These are credentials that can be stored on digital devices, and you can use cryptography to verify their data and authorship. It could be maybe an ID card issued by a country or your driver's license to provide your age or address. We believe digital credentials are going to be a big thing in the future of digital identity. And there are already standards from W3C for verifiable credentials and from ISO for mobile driver's licenses. Now the challenge is that these are relatively new and can be complex to understand and implement. This is where we come in. Using mobile driver's licenses or MDL are cryptographically verifiable driver's licenses. As of today, there are some states that allow you to store your MDL in your Apple wallet, so it can be presented in person, for example at TSA when you're at the airport. Google is also working to support this as well, which means these credentials will start getting adoption everywhere. This has huge implications. Users will be able to use MDL to simplify, know your customer or KYC processes, implement credential recovery mechanisms, and even sign in into applications. And as always, true to how we've operated and built our products, we want to make it easy to work with these mobile driver's licenses. As we're working to support online MDL verification, which will be available next year. But that's not all. We are thrilled to unveil our brand new site dedicated to developers to understand this spec, mdl.me. So you can dive deep into the heart of the MDL specification and play with hands-on dynamic examples. With mdl.me, you will learn how mobile driver's license are formatted, verified, and how all parties in the ecosystem work together. Now, let's talk about our innovations in scalability so that we can keep up with your business's growth. I'd like to invite Bhavna back in the stage to talk about that. So let's deep dive into developer productivity. This is all about making your work easier, more efficient, and more impactful. So I have a question for you. Name the company that had the fastest user-based growth this year. Yes, OpenAI. The one company that grew the fastest and everyone is talking about. As a login provider for OpenAI, this meant we had to meet that growth rate. The high-scale capacity required us to apply architectural changes and to tell you the story of this scale journey. Let me invite our chief architect for customer identity, Mark Walker. So, Bhavna, the fun thing about this story is just how fast it happened. When OpenAI introduced chat GPT, it was a smash hit. They quickly accumulated millions of users. When a customer goes viral, that means we have to go viral with them. So to accommodate OpenAI's growth, we needed to move fast to upgrade our capacity. So over six months, we upgraded the largest cloud environments to handle over six and a half times the amount of requests per second and raised that limit from 1,500 to 10,000. We've not only managed to improve the scale of the platform that it can handle, but we've also made numerous improvements to make it more resilient and efficient. High-scale for us doesn't mean just scale. It means scale, resilience, and efficiency all at once. You don't have to choose. And by the way, we're already working on doubling that 10,000 request per second limit again. Odds0 always has been built with developers in mind. And we continue that journey with Octa now. Whether it's getting you started, helping integrate with our universal login into our application, or provide you with the tools to configure every feature we offer. Our developer experience team is always dedicated to making your life easier and enhancing your experience. This year, we are working on bringing two clouds together so that we can leverage their combined power to create seamless experiences for customer identity cloud SaaS builders and workforce identity cloud enterprises. As a SaaS builder, you want quality exposure of your product to potential clients. And we can hope with that by allowing you to quickly make your application available on all Octa workforce customers via the Octa integration network OIN. The OIN is a catalog of integrations that enterprises use to give their workforce seamless access to the technology they need. Having your application listed here will allow you to reach thousands of potential enterprises. Because you're using customer identity for your SaaS app, as we add capabilities to customer identity cloud, your customers using Octa workforce identity cloud will get features like provisioning, governance and risk signaling without you having to write or maintain a single line of code. I'm really excited about this as it is something that only Octa is positioned to do. And it showcases the power of our two identity clouds. You might have heard the word passkey once or twice this week. So this session is pretty much an introduction and going a little deeper to understand what a passkey is. It's pretty much three main topics, what, why and how. We want to talk about passkeys and where they're actually coming from. They are pretty much a brainchild of the fight alliance. Their mission has always been to reduce the world's overlines on passwords. Now, to passkeys. The most important part is that it's a cryptographic credential and it's bound to the verifier. So mainly it's the domain or it's called relying party or relying party id. And with that, they are phishing resistant. And passkeys themselves, they can be used as a primary authentication method. And that's because the key material as well as the metadata are stored on the client side. So they can be discovered and the authentication flow doesn't need any data from the server. The main thing that server can do persists to public key. So in the future it can verify the assertions coming from the client. And there's also the attestation itself that has more data about the authenticator. And Hans will go more into detail later. And then the authentication flow is very similar right now. I have a key for the domain. Again, download the challenge. It's bound to the domain or the rpid. It gets signed and then the assertion goes back to the server. And the server can use the public key to validate this is legitimate authentication. And because of the challenge, it cannot be replayed. We want to now look what kind of authenticator types there are. So there's platform authenticators. They're pretty much integrated in the operating system. You probably already use them. For example, windows hello, apple touch id. On the other hand, we have roaming authenticators. Those are additional devices that you can carry around and they connect to your device. And very new are passkey providers. Those are pretty much extensions to the platform authenticators. So there are discoverable credentials. They were previously called resident keys. And if there's discoverable credentials, there's most likely also non-discoverable credentials. And those are also called non-resident keys or server bound keys. And that means the key material is actually not stored on the client side or in the authenticator. It's created by the authenticator and encrypted with the key that only the authenticator has. And then sent to the server and stored there. And every time I'm authenticating, I pretty much have to download that encrypted blob first. Now, if you overlay that, how that all fits together, there's discoverable credentials on the left, non-discoverable on the right. And platform authenticators, they're mainly discoverable credentials. Roaming authenticators can be both, but the way they are used today, they're mainly used as non-resident keys. And passkey providers, obviously, today, they're all discoverable. And for us, that means that there's great overlap between discoverable credentials and passkeys. And this is how CIC is using it or the customer identity cloud. Pretty much roaming authenticators will also be discoverable credentials. We talked about the why and how great it is and how great the user experience is and the security. I'm going to get into more of the nitty gritty of what do I need to keep in mind when actually adopting this in reality. So kind of the big pieces should be pretty obvious is registration, authentication, and account recovery. Those are your three primary angles for any sort of authenticator experience. And then I'm going to touch in and probably weave throughout the heterogeneity aspect of just, you know, The diversity that's in the ecosystem right now. So a couple things that are different when passkeys, when registering a new user, is that user Verification and consent may or may not be there, but that may be important to you for if you're going to use this as two factors or one factor. So some passkey providers have just a user presence check and not full biometrics. And so that should just be one factor. So you may want to do a step up, depending on your security posture for that. But if it does have user verification, then you know during registration, hey, I can use this as a two factor. And you're good to go. The way you do find that out is there's metadata. Do keep in mind that for discoverable credentials, that metadata is stored on the authenticator. So don't put any PII in there. And then the attestation, this is how you find out the properties of the key that comes during registration only. So do check during registration what the properties of the key are that you just registered so you can know how to use them down the line. Additionally, some providers will give a signed attestation that says who they are. It's called the AA GUID. Basically it's a fancy way of saying the universal ID for them with FIDO itself. And you can go look that up on the MDS that FIDO hosts so you can get properties about that provider. Now, less on the technical side, more on the philosophy side. Things that matter during registration that you should keep in mind, especially now as the ecosystem is being built out. Order does matter. So if you make a platform bound passkey, you're going to have a harder time setting up a second device. And so make sure, especially like the desktops, they haven't quite gotten to the sinkable fabric stuff yet. So do try to build in like set up two or be aware that you have some sort of path to create a second passkey if it does happen to be device bound for their first passkey. Especially hardware bound passkeys do have a storage limit. And so you're more security conscious. Users who use physical tokens may not want to do a discoverable credential. If you think that's a large part of user base, do keep that in mind. Maybe you want to build some optionality there. A really important part, the way you get phishing resistance is binding it to the domain that you use to authenticate and register it on. So your registration authentication should be on the same domain because that is what you're binding it to. And also you cannot change it in the future without having to re-enroll everybody. Like your domain and be confident in your domain when you start rolling out passkeys because that is what you're being bound to. And the reason is that if you start shifting your domain around, that is the same thing as a phishing attack. There is no way for the authenticator to discriminate that. And that's a function of the phishing resistance. And so it is locking you in there. And then also revocation, it is different than passwords. Do be aware of this. With the password, you know you have old password, new password, type it again. It's an atomic action. With passkeys, that's not the case because the authenticator is involved. The authenticator is actually creating the key that you're using and registering. So make sure to register the new passkey that you're replacing before revoking and getting rid of the old passkey. Onto authentication. And this is the cross-device authentication piece. This is actually very helpful, especially for creating a second passkey on a new device or in limited input devices. What this does is that if I have, say, my desktop where I don't have a passkey yet, Or it's like one of these hotel computers I just go and need to log into real quick to print something, You can use this cross-device authentication flow where it shows a qr code. And then I can take my phone, which already has a passkey, and use the authenticator there to get a session on the other device. So it's very handy for a lot of scenarios and do try to take advantage of it. The OS and browser handle a lot of that for you. Passkeys are not identity-proofing. It is an authenticator token just like a password. People can share passkeys. The same way they do password sharing. A lot of the new sync fabrics that are being built. For instance, the apple ecosystem, you can airdrop it to another user. So don't consider this bound to a user. It is bound to a user account. So if you have password-sharing issues in your product, you're going to have the same issues with passkeys. So you need to solve that separately. And then biometrics aren't always useful. A lot of the passkey providers do have a pin fallback mechanism. But in case it doesn't, do have an escape hatch for your users in some manner. So sync fabric. I have said this word a lot. I have not told you what it is yet. So let me get into that real quick. So the sync fabric is new in the past year or so. This is the part that we really think will drive adoption for passkeys. Because before, it was all device bound. And so you really had the adoption problems, especially in consumer scenarios. Where people lose their devices. Their backpack takes a swim in a lake. And so you had this hard deal with losing the only thing that can get you into a website. So the sync fabric was created to help solve that problem. So now instead of being hardware bound to a device, The passkey is stored in an encrypted blob in the device. But it's software backed. And it is then backed up to the cloud. And then pushed down to new devices. So what's great about this is that you No longer have to solve the new device scenario. The sync fabric solves that for you. So they're in charge of new devices. And so by making a lot more like a password manager experience, We're really hoping that will unlock a lot of these scenarios. The last piece that should happen very little but is the one that Gives everybody nightmares and headaches, account recovery. Again, like we've been saying, it's no longer just your responsibility To do account recovery. It's not just you have a password Hash stored in your database that you have to take care of. It's now a shared responsibility between you and the sync fabric. So new devices, that's the sync fabrics problem. They own that. You may need to guide them to the Correct place so they can do that experience. But that is now the sync fabric. What you own is the total disaster Scenarios. They forget their sync fabric Password or something weird happens and they no longer Have access for other reasons. The sync fabric was the key For some mysterious reason. That's where you step in And do the normal account like email magic link or call a Help desk or what have you. And do try to guide your users To the correct sync fabric. The sync fabric owns new device, But not all sync fabrics go across all ecosystems. We've touched on a bunch of things, but do keep in mind That this is an evolving ecosystem. It's a year old. Everybody is building out support. Some pieces are still being standardized, Especially around the sync fabric. The browser experiences are in Early sages but they are iterating extremely rapidly and making It better and better every day. Something that we as octa or The phyto alliance cannot do ourselves is educate the users. We need your help with that. That's going to be a global Problem. Everybody's going to have to do this together. So users don't know what pass keys are. They may have heard it a few times in the news, But you're really going to have to educate them and bring them Along with you to this better world. We've gone over a lot. I just wanted a last little summary slide of kind of all the Things we've talked about here. The real key i think on this Side is that far left column. Fishing resistant. That's the one thing passwords don't have that this does. And that's the thing that all of these different types and all These different scenarios we've gone over of pass keys do have. That's the big win here. I know i've gone over a lot and There's even more complexity. So this website i found very Useful to keep an eye on. Pass keys dot dev slash device support. But also what if you don't have to worry about all this complexity? You know, octa can do this for you. So if you want to get this into your c-i-c senate, it's Really, really easy. And all you have to do is Change to an identifier first flow because you don't need that Password anymore. Go over to your authentication Method settings and turn on the toggle. That's all it takes. And now you have pass keys. I'm erin peracky, senior security architect at octa. I also work on a lot of the standards of often open id Connect and skim. We're going to talk about the Difference between how enterprise companies expect to deal With identity problems and how that's different from how Consumers expect to deal with identity. We'll talk about how Single sign on works and get into a little bit of the details On open id connect. You are probably familiar with a Typical login box with a username and password. And this can get you pretty far when you're building a sass App. You may also then quickly realize That you need to support other social identity providers In order to be able to reduce the friction of onboarding Or just getting users to come back into your application. Maybe you've even added support for pass keys into your Application. What's interesting though is that these All have something in common. The user's account is their Own account and they're all like isolated bubbles from Each other. From your app's point of view you just Have a bunch of users. This can take your sass app pretty Far as you're growing and scaling your business. You may then realize that actually what people want is People have team accounts. So let's say you go and Team support into your application. But as we're quickly Growing and adding more and more of these kinds of features We're getting closer and closer to what it looks like to be A fully enterprise ready application. Let's say that There's that one user of your app who now loves your app So much that they actually want to get their whole company On it. In fact their it department wants to You know do a site license and their it department says Oh well we are not going to let those users login With their own password to your application. We're not even Going to let them have their own google account or social Login. Instead all the users are going to sign In through the enterprise company's sso provider. And there's a lot of benefits to this from the enterprise Customer's perspective. There's one place to manage Credentials. There's one place to manage multi factor Off. If they want to require that all employees Have multi factor of a certain type they can do it in Their sso portal. There's one place to manage who has To which applications. And very importantly it gives them a Single place to revoke access when needed. In order for your Application that you're building to support enterprise Customers like these you need to support doing a single sign On flow to their identity provider. So from your Perspective each enterprise customer is going to be a Completely different identity provider. And it's kind of Like if each enterprise customer was a different social Connection like Facebook or Google. So the good news is That it's not as complicated because there are open Standards for this. So you can write the code once and Then configure it to different identity providers. Instead of logging into your application with a password They're going to enter just their email address. And when they enter their email address your application Can discover which identity provider they should be Using to log in and send them on their way over there. So from your perspective as a SaaS developer you're going To be seeing the world like this where you have your App that's the center of your world and you're Connecting out to a bunch of different identity providers. From the enterprise perspective they see their Identity provider as a center of their universe. And they're going to see that as where they manage Everything and how they're able to let applications Connect to the enterprise and they're going to be Picking and choosing the best of the SaaS apps that They would like to use and putting them all together Under the enterprise IDP. Open ID Connect is actually Built on top of the OAuth framework. Open ID Connect is not about getting access to data It's about signing in. The main thing that you're Going to be dealing with in Open ID Connect is called An ID token. So the ID token is how the Server encodes data about who just logged in What happened, any attributes about them. And the tricky part about this which trips up a lot Of people is that ID tokens are defined in the spec As a json web token as a jot. That is Open ID Connect. So in OAuth access tokens don't have to be Jots but they often are. And there are good reasons To do them to use Jots as access tokens. However, even though these two tokens might be Jots They are not the same thing and you cannot mix them Up. You can't use them interchangeably. I like to think of an OAuth access token as a key. When you get a key and you go open a door like you don't Really care what are the little jaggy things on the key Mean. You don't need to know that. You just need to know that you can put it in the door And turn the key and the door opens up. Open ID Connect on the other hand, that ID token is Something you are expected to read when you're building An application that's going to be receiving an ID token. It's like a receipt where it says, the OAuth server Says this user logged into this application on this Date with a password or with MFA and things like that. So the audience of the ID token will be the client that Got the token. The audience of the access token is Going to be the api where you're going to be getting data from. Let's walk through what it will look like to actually start Building in an open ID connect flow into a sass app. You're going to take out your password field. You're going to put just an email address. They're going to type in an email and if it matches Email domain of a customer, you're going to look up The identity provider for that customer that you've got In your own little database of configuration and send them Off to that customer's idp to log in. Let's say they entered a company email address. You did the sass flow using open ID connect. You got back to your app and now you know who they are Because you are able to read the id token. You're going to then need to have some concept of that User in your own app database. So you'll put a record in your database like user id One came from tenant number one and their external user Id was this and then if users from a different company log in You might have user id four came from tenant id two with this User id all in your local database. So actually there is a claim in the id token called subject Which is a stable unique identifier for that user at That identity provider. So this is probably closer to what your database will Actually look like. The actual flow at a high level is you're building This application, this client and this flow it turns out Is going to be the same whether you're building a mobile app A single page app, a web server based app. Start with the client and have your login button and then Redirect the browser to the OAuth server. That will send the user's browser over to the authorization Server where they're going to log in there. So that's where the user sees their password prompt. They don't see a password prompt in your app. Once they log in it's going to send this authorization Code back into the browser which brings it back to your application. You can then go make a request directly from your Client application to the authorization server exchanging That authorization code for the id tokens. So what the user sees is a prompt. They enter their email address. You'll decide what to do with them like redirect them To their enterprise identity provider. You're not going to see what happens here Which is the entire point. They're going to log in with their own company password Their own multi-factor auth and eventually they get Sent back to your application where you can do that Code exchange in your login. The step by step of the OpenID Connect flow If we just look at the URLs and the data moving around The first thing that happens is your application builds A URL like this to the OAuth server. This is where they're going to see their login form At their enterprise IDP. Then they're going to do whatever sequence of events Their IDP says they need to do to prove who they are And that server will then create a redirect Back to your application. And in that redirect will be this long string Called the authorization code. Which that's what you can use to get the ID token. So you're going to get this in a redirect Which means you're reading it out of the address bar. You take that, you make a post request Back to the OAuth server exchanging that authorization code For the tokens. And this is the same in OAuth and OpenID Connect Where you're doing the flow this way. The nice thing is that you can actually get both tokens at the same time And notice that they both kind of start with the same few letters Because they're both JSON web tokens. So you grab this ID token from this post response that you just got And now you're ready to actually figure out what does this mean. So a couple of interesting things here Again subject at the top. That is the unique identifier for that user At the identity provider. This identity provider is identified by the claim issuer ISS Which is that one And that is the identifier of the OAuth or OpenID server So that pair is what you can use to be like Oh, is this the same user that I've seen before? And then the rest of these claims are Either profile or login information So we've got like a user's name and email Or in their time stamps of when the token was issued When it expires. AMR is telling me how the user authenticated So this is actually a really important one If you know that your application has requirements That you need all the users to have a second factor You can actually put that in the request of the OAuth server And they will get prompted for a second factor And then you can confirm it by looking at the AMR claims here Off time, I think this is an octa specific one But that's the time stamp the user last entered a password In case that's relevant to you And these are the kinds of differences that you might see Depending on the particular OpenID connect server you're talking to Sometimes these claims, they add like their own custom claims in here But that's how you can grab the user's info I want you to meet Alice Alice is tech savvy and what the kids call Extremely online Alice has accounts on just about every platform you can think of From social media to streaming services And she utilizes her trusty email address As a universal identifier Unfortunately, one day Alice loses access to her email Oh no, right? All of her two-factor authentications and app verifications Are tied to that email address So now, every app and service that collectively Form her online identity Is now suddenly out of reach And despite being the rightful owner Alice cannot retrieve her content Without access to that email This unfortunate incident It highlights the vulnerability of the current web And our inability to own our identity And control our data But wasn't the web meant to be decentralized? Indeed, it was However, it's missing a key element that enables it An identity layer So applications that require user accounts Have to collect our information In order to persist it with our content What if we could own our identity And our data across the web? This is possible with Web 5 So Web 5 embraces the convenience Of the account model of Web 2 But it restores control back to the users And ethos of Web 3 And this platform enables developers To build decentralized applications While abstracting away the complexity Of doing so So Web 5 is comprised of three core pillars All of which are based on open web standards We have decentralized identifiers Also known as DIDs or DIDs Verifiable credentials And decentralized web nodes So the identifiers that we know and use today Are controlled by some intermediary For example, my email address is an identifier That's associated with me I've built a following And created a brand around this lovely handle Right there But what we've seen with the rebrand of Twitter Did y'all see the stories where some of the handles Were basically repossessed Or repossessed Or repossessed Or repossessed Or repossessed Handles were basically repossessed Someone had the cool handle X How cool is that? Snatched right from them Someone had ad music 16 years they built a brand around that handle And overnight it was taken from them Because it was never theirs to begin with So before we can realize Truly decentralized applications We first need decentralized identifiers Decentralized identifiers are the only parts of Web 5 That optionally touch a blockchain It could be used on any blockchain Or no blockchain at all For example, this first one is an identifier That is anchored on the Bitcoin blockchain The second one is anchored on Ethereum And the last one doesn't use blockchain He uses the Web Now because that string is anchored somewhere And it's standing by itself And it works as a URI That points to more information About the dead subject That information is stored in what's called A dead document And that document lives in some decentralized storage system Such as IPFS The document itself is a JSON file And it describes how to engage With the dead subject The next pillar of Web 5 Is verifiable credentials They work hand in hand with decentralized identifiers To enable trustless interactions Meaning two parties don't need to know Or trust one another in order to engage I have an example Let's say Alice is applying for a loan But the lender needs to verify a proof of income So Alice's employer, ACME Will issue a verifiable credential to Alice Which she then keeps with her She can store this in something like A digital wallet, for example Let's double click inside of that credential To see what's there So we have the issuer, who is ACME And then we have the subject, who is Alice More specifically, we have their decentralized identifiers Here, right? And then we have claims The issuer is making about the subject So ACME is saying, hey The person who has the decentralized identifier Did example Alice Her real name is Alice Smith And her salary is $120,000 And then ACME has cryptographically signed This verifiable credential So Alice keeps that in her little digital wallet And then when the lender Ask her for proof of income She can present this verifiable credential to them She cryptographically signs it as well And now the lender can continue on With the loan application Now remember, this lender doesn't know Or trust Alice doesn't have to It considers ACME a trustworthy entity They know that it's ACME That the decentralized identifier was there Cryptographically signed Therefore, ACME has extended trust to Alice The last pillar of Web 5 is the centralized web nodes So today, centralized entities act as our data stores All of our content, our preferences Are stored in these apps' servers The centralized web nodes changes this By enabling us to decouple our data From the applications that we use And instead, host our data with us Blue Sky is a good example But instead of things like your connections And your tweets being stored with the app Is stored with you in your own personal data store What this means is if the centralized Instagram Or the centralized TikTok pop up I can take my connections I can take my data in all of this And go to those apps with it intact Now the centralized web nodes is capable of hosting Both public data as well as private data So in the case of something like a blue sky You will want stuff like your connections And your tweets to be public And then things like your DMs You want to be private Now the web nodes are also not Hosted on a blockchain They're hosted with you Now while this does offer a paradigm shift In the way that we exchange information It's not a total overhaul of the web That we already know Works kind of like a progressive web app Where if you had a decentralized web app You would add a Web 5 SDK in the flow And then the app is free to truly go serverless Because it doesn't have to host that data itself Now remember the did document And we said that did document has things like The public keys and the authentication And verification methods It also has another section in there For service endpoints meaning How do I communicate with this did subject Where does their data live And in that part of the did document Would be you arise to a did subject The centralized web nodes So given an application has my did I authenticated with my did It's able to resolve that did See the did document It sees where my web nodes are It can send HTTP requests To those web nodes for information This snippet is a query That is asking for all of the objects In the web nodes that follow Social media posting schema So the data that's in the web node Follows some semantic type And that's what makes it interoperable Across applications Now of course all of this is pretty complicated Especially for non-technical users So as I often remind builders in the space The centralization is not a feature That your users are requesting right It should be an implementation detail So we are also building identity wallet That will allow users to Manage this in a really user friendly way Where they can manage multiple identifiers So web five enables developers to Build decentralized web apps And it sits on top of this web five stack These three yellow things again Are open web standards Meaning they don't belong to any one company Given this it's all open source You're free to use it But you don't have to worry about The implementation details Of making your app decentralized That's taken care of You can focus your attention On what you truly care about Which is your app So let's say that Alice uses Spotify And she wants to try out Title with web five How this will work is Instead of Spotify writing her playlist They would write that to her Decentralized web note Then when she wants to try out title She gives them read access And they can read all of those Music playlist objects That have been written to her web note No matter which app it came from Medical records You see Alice she has A primary care physician She has a gynecologist She has a dentist Now when she moves You don't want to call these doctors Offices and plead with them To fax the information over to this other one And pray that they actually do it She's given each of her doctors Read and write access to the patient records In her decentralized web note So they can write those records there Now remember they're all using Decentralized identifiers So any of these doctors can see Who has written that record And be able to verify that Yes that is a reputable source I want to show you web five JS which is a library that we've developed It is in tech previews Because it's a JavaScript library NPM install works just fine Then I'm just going to import Web five from Web five API Given that When I'm ready to connect So a user has come to my application What I'm going to do is Call web five dot connect And this connect function is going to Look on the user's device to determine Do they already have a decentralized Web note that's local to this device And a decentralized identifier And what this is going to return is Let's say const It's going to return us an instance Of web five so that we can do Further actions and it's also going To return us the decentralized Identifier for this user Now let's say we want to start Writing to this user's decentralized Web note The objects in there are called Records so we can say Create a record And we'll say const Record Equals a wait And we're going to use that web five Instance from there notice here I have an agent that's like the wallet So I have the did thing so then I Can start doing things with the did Like resolving it and then there's DWN that's for the web notes and BC for the verifiable credentials So we're going to say DWN Records. Create When I create a record I need to pass In two things one is the actual payload And then the other property Here is a message So this is where I put metadata About that payload I can put By default the data that is Written to the web note is private So if I wanted this to be a public Record I would publish it So I can say publish equals true And that makes that data publicly Available and then this is Writing to this user's Web note but let's say this is An application that's facilitating Communication between multiple people So I would say recipient and then Put another did here There's multiple things you can do There but that will create a record It will write that to the decentralized Web note And let's say I want a query for some Records to do that I would say const Records And I'm going to use Web 5 DWN Again and we'll say Records.query And from here I can specify What sort of Message I want And I can give it a filter And then I can specify the type Of data I'm trying to read from that Record and then last thing is delete How would I delete based on this Await record That delete This is Web 5 In action as you can see We've kind of abstracted away A lot of those details it's not hard To use you don't have to think about Cryptographic keys how to do All of this stuff all of that is done In the background when I've written And deleted these records it'll happen On their local Web note But then sync is done In the background on an interval So it'll resolve their did Look at all of their remote Web notes And make sure that all of that stuff Is synced up together on a schedule That is Web 5 In a nutshell Like I said it's all open source So you're welcome to use it Don't publish your Web app just yet until I tell you that it's ready to go You can play around with it You can also contribute to it And help us make the Web that we All deserve one where we Own our identity And control our data Thank you so much Thanks for joining us for our first Best of Octane for Developers Webinar To dig deeper into enterprise integration FGA, pass keys and much more Head on over to developerday.com And watch full sessions from throughout the event I hope to see you there next year Happy coding!