 a quick safe harbor legal slide that everybody's seen before here, so I'm not going to linger on this one too long. Okay. Welcome fellow developers. My name is Martin Walsh. I'm a Director of Engineering at Okta, and I'm excited to talk about the power of SDKs with you today. This talk is a personal story, and it's a life I've lived for the last six and a half years from joining Orsito to Okta today. In that time, I have grown from a senior engineer to a director. And SDKs has been one of the constants in my journey, which has put me in a unique position to tell the real story of our SDKs and how we empowered our customers, who are you, our developers, to be successful. Over the next 25 minutes, we'll see the impact our SDKs have made in the world of identity, their role in streamlining the integration of authentication in your apps and how delivering a great SDK with a delightful developer experience and providing a secure by default approach can enable you to empower and level up your fellow developers. Time for a quick show of hands in a virtual show of hands in the chat. How many people here have used an SDK or library? Great. I would expect everybody. Now, if I was to change this and ask, why did you use an SDK? And please, if you're online, please put it in the chat. Tell us why you used an SDK. You might answer, it's easier than building it myself. It saves me time, or the tutorial told me to do it. It should be easier than building it yourself, and it should, in turn, save you time. As developers, we're often solving complex technical challenges in our applications. There are many demands on our time, and the more focused time we have that we can retain for our own development time, the better. Identification is the first step in most online transactions and requires a user to identify themselves, typically through an authentication process providing a name, email address, phone number, or username. Providing secure authentication is a critical component of any application. As a developer, I don't believe you need to be an identity expert to integrate and harness the full power of our identity platform. Let our SDKs empower you, as a developer, to effortlessly integrate with our identity platform. Let us make the hard things easy so you can deliver, like an identity expert, in only a few lines of code and deliver a secure by default experience for your users. Simply put, it should just work. Seven years ago in 2016, I experienced this firsthand. I was adding identity to my own iOS application, and I didn't want to only use Facebook login and tie myself into a single identity provider or have to implement and maintain multiple identity provider integrations. I searched and looked for a better way and discovered a solution from a plucky little startup called Osero. I quickly tried out their QuickStart guide for iOS, and I was able to integrate their authentication platform into my application in no time. I was impressed with the SDK, the documentation, the guidance, and it was nice when things just work. And it often reminds you how sometimes low the bar is, where you're surprised when things work. It's a nice joy when things just work, and that was my experience of Osero. And I'm not sure it was, but something at the time felt special about the product. It solved the essential identity building blocks needed for almost all apps, not just providing a flexible platform, but heavily investing in the developer experience and empowering me as a developer to be successful. This was built for developers. And at the time, I wanted to learn more and discovered Osero embraced finding the best talent anywhere in the world with a remote-friendly culture as part of its DNA, and this was over seven years ago. I reached out and the rest, as they say, is history. To demonstrate the power of our SDKs, I will share a little history of our Osero SDKs. We'll look at some innovations we developed that helped us stand out from the crowd, how this contributed to building developer trust, and how our love for making our developers successful became a rocket ship, taking us from hundreds of weekly downloads, blasting off into the stratosphere and delivering over 73 million downloads a month. And every time I look at this slide, it's, I know, it's a very proud moment and looking at the number of downloads. It's not something I ever really looked at until putting this together. And that always surprised me. It's just incredible to see how popular SDKs are. So please join me on this enlightening journey as we learn how to unlock the power of SDKs and realize their ability to delight developers, build trust, and ensure you are empowered to deliver the most secure identity experience possible for your users. To build or not to build, that is the question. I sometimes get asked, when should you build an SDK? At what point does it make sense? Let's look at an example. What might it look like if we were to switch this into an authentication workshop? And the ask was to build a simple authentication API MVP. For this exercise, we'll not worry about the challenges of cryptography. While identity has significantly evolved over the years, most developers first thought is a classic username, password, database authentication system. We can see in this postman mockup, we present a simple authentication API design that takes a username, password combo, and returns an access token that you can then use to access your own protected resource, which is typically your own company's API. Access tokens are crucial in the context of modern web applications and API-based architectures, as they provide a secure mechanism to authenticate, authorize, and manage access to resources. They play a vital role in ensuring the security, privacy, and proper functionality of these systems. In my early career, I've implemented this database authentication model many times, a simpler time perhaps. And when friends ask me now about implementing authentication, I start getting flashbacks to all the challenges that we've had and we've faced over time, and simply say, please don't waste your time building, securing, and maintaining your own. Try all zeros. It's important we look at platform API design as an SDK is, in essence, a reflection of the API provided by your platform. Now, as a developer, ask yourself, is it worth investing the time in building an SDK for this simple authentication API? Perhaps documentation and guidance is enough. After all, it's only a single HTTP call. For me, this is a little bit tricky. In strict isolation, the answer does seem quite simple. Yet, I can't help thinking about the thousand fragmented developer implementations and the inevitable evolution of this API. Let's take a look at modern identity. I recently read a comment on social media that OAuth is hard. And it got me reflecting on the evolution of modern identity and the multitude of requirements for delivering a first class identity experience. And then you have OAuth2, cryptography, GWTs, token rotation, open ID connect, and lots more. Wow, that's a lot of requirements. In response to support all of these features, the identity platform protocols must expand to support a growing number of identity use cases. In turn, the complexity increases dramatically for the developer. Integrating with this API, it is no longer a single HTTP request as we saw before. As a developer, you need to be more aware of the authentication flow and support a wider variety of identity use cases. On top of this, for every platform, all framework you develop for will bring its own unique challenges. For example, writing a spa app in React will present a different challenge to a native mobile app in iOS or Android. And again, there will be a different challenge writing a web application in Python, for example. One of the most critical identity implementation details is how will you securely store tokens and user information? Are you able to invest the time in both becoming an identity and platform security expert? I don't believe you should need to become an identity expert and a security expert to be successful. Let us make the hard things easy and empower you to be successful with our SDKs. This is the power of SDKs. Making the hard things easy. How do we, as developers, make it easier for other developers to be successful? First, ask yourself, what outcomes are your developers trying to achieve? In the case of identity, the top outcome is to authenticate an end user and securely store their tokens. The developer doesn't need to be aware of the hidden complexity to deliver this. This is our opportunity to make a hard thing easy. And how do we do this? Your SDK should target the 90% use case out of the box and delight developers with an effortless integration experience, enabling them to achieve the top outcomes in only a few lines of code. But what about the other 10%? It's important that the raw primitives of our SDKs are still accessible for those developers with more advanced use cases that may not yet warrant solving within the SDK due to the complexity versus popularity. For example, imagine you have a single customer with an unusual use case. You could add the complexity of the SDK. That would, of course, make that customer very happy, but now you have a much more complicated SDK and you have an increased maintenance cost and you're providing, whereas in this case, providing sample coding guidance may be the best initial approach. Yet, we should always remain curious and look for opportunity to make the hard things easy. If we see a use case become more common, then you might want to ask yourself, is it time to upgrade this solution from sample code to a first-class SDK method? I'm going to walk through a couple of examples of how being curious and having empathy for our developers enables us to innovate, differentiate, and stand out from the crowd. Let's talk about identity in mobile apps. Every platform brings its own unique challenges, especially when it comes to ensuring your tokens stay secure. Once again, we don't expect our developers to be identity security experts. We take a secure by default posture in our SDKs that developers can trust. I will start with my favorite example because I wrote it, which became a differentiator in our mobile SDKs, a feature that made developers very happy and it became an expected feature across our entire SDK product range. Let me take you back to the year 2017. I was a senior engineer at Osido, full of dreams and working on our Osido iOS libraries. Every day, I would read every bit of feedback and we received and engaged directly with our open-source developer community in GitHub, which I really enjoyed. Being able to get feedback directly from developers was a gift. In mobile applications, the top authentication pattern is to make use of a refresh token as part of the OAuth 2 authorization framework. A refresh token is a mechanism to maintain a long-lived access to protected resources without requiring users to frequently re-authenticate, which in mobile applications isn't an ideal experience for the user. When a user authenticates, an access token is returned, which will be valid for 24 hours. After this time, it will expire and you'll require a new access token to maintain access. We can now make use of the refresh token string that was originally returned during the authentication. The refresh token has a longer life and we can use this to request a fresh access token. Sounds pretty simple and it didn't seem like an unreasonable ask at the time for the developer to manage this themselves. We had provided an SDK method to obtain a fresh access token using the refresh token. In our documentation and quick starts, we demonstrate the refresh cycle and how these tokens can be securely stored using our simple keychain iOS library. And we also provided sample code repos. What could possibly go wrong? Well, it turns out quite a lot. It was a humble reminder that you are not your customer. As both a platform and identity expert, I had an understanding of what the happy path looked like as I was in the code every day. However, we can't assume that our developers have the same level of expertise. So what did I do? First, take a step back, breathe and then reflect on the outcome the developer is trying to achieve. They want an access token. They want their tokens to be stored securely. Those are the outcomes the developer is trying to achieve. So how did I make this hard thing easy? I built a lightweight token management utility class and added it to the SDK. It was easy to configure and any time the developer needed an access token, they only had to call a single line of code and would be returned a fresh access token. This utility, known as the credentials manager, would automate the following tasks. It would check access token for expiry. It would return a fresh access token using the refresh token if it had expired. And it would also take care of storage, securely storing tokens in the iOS keychain. This was a big hit with developers and we got fantastic feedback. Folks in the field told us it was a differentiator and quickly became a much requested feature for all our SDKs. We had set our developers up for success by reducing complexity and ensuring the happy path. In retrospect, my only regret was naming it the credentials manager when token manager would have been a better name. Naming things is always hard. Over the years, the credentials manager has evolved hand in hand with our identity platform. When we introduced refresh tokens, sorry, rotating refresh tokens, this was a new product to enhance the overall security of the token-based authentication process. This involves issuing a new refresh token alongside a new access token each time the application requests to refresh the access token. This ensures both the access token and refresh token have a limited lifespan, reducing the window of opportunity for an attacker to exploit a compromised token. For developers already using the credentials manager, they only needed to update their SDK to the latest version and they could instantly make use of this new feature with no code changes required. Now that's a delightful developer experience. We had taken care of the additional complexity behind the scenes. Our developers didn't even need to think about it and could enjoy the additional level of security hardening in their application. This is the power of SDKs. Let's explore another scenario. What if a developer is building a single page application? A SPAR is a web application or website that interacts with the user by dynamically rewriting the current page rather than loading entirely new pages from the server. This approach can result in a more fluid and responsive user experience, reducing the need for full page reloads. However, we're no longer in the beautiful Apple ecosystem of iOS, we're in the world of JavaScript and things can get a little messy and staying secure by default becomes a more significant challenge. The Osido SPAR JS SDK was a brand new SDK we launched in 2019. It embraced many learnings from all previous SDKs and the goal was to deliver the best possible developer experience yet. And one of the other goals we had was to deliver the smallest package size in the market. We had customers with end users and markets that relied upon emerging mobile networks and every byte counts for their user's experience. When we launched VR1, our package was 6.97K minified. By comparison, at the time, some of our competitors weighed in at 60K, 65K, 98K. It was a fantastic achievement to deliver such an efficient SDK knowing that we would delight our developers. Shifting focus to being secure by default. In 2020, as part of our continuous security reviews, our ever-diligent security team recommended we evaluate web workers to store and refresh tokens when storing tokens in browser memory. A web worker is the JavaScript feature that allows you to run scripts in the background separate from the main execution thread of a web page. This would let us separate the refresh token from being stored in the in-memory cache inside the memory's application space. Yet, when we dug deeper into this, our team discovered the following. It would add a lot of complexity to the SDK. It would be much harder for us to debug. Internet Explorer support was going to be problematic and our much-loved bundle size would have to increase in response. Now, we could have provided this as a best security practice through guidance and documentation. However, as we saw before, when you have high complexity, you're going to create potentially significant barrier for the developers to be able to adopt this feature. There was a good chance developers could actually get this wrong and we didn't want to set developers up to potentially fail. Security identity is a top priority. While this security feature would significantly increase the complexity of the SDK and result in a higher maintenance cost for the team, the additional level of security benefit it would deliver for developers was well worth the trade-off. In the end, it turned out to be an additional 1,218 lines of code in the SDK. This would be a crazy ask to ask developers to roll this themselves. Our developers required zero lines of code to be successful. They only needed to update the SDK to the latest version and they could instantly make use of this new security feature with no code changes required and get one of the strongest security implementations possible. After implementing web workers and enabling IE11 support, along with various product feature additions over time, the bundle size had increased to approximately 21.4K. Although this was still tiny versus our competitors, for a team with high standards, it was very disappointing. Fast forward to today, we have the Spark GSV2 SDK. Reflecting on our V1 learnings and developer feedback, it maintains all of the security hardening features and improves upon the already stellar developer experience in V1, yet now weighs in at only 13K, secure yet nimble. This is the power of SDKs. Two great examples, and as many more I could talk about, yet there's only so much time. Let's recap on the power of SDKs. A reminder for everyone here, stay focused on empowering developers. Listen and truly empathize with your fellow developers. They will tell you where the pain points are. Stay curious and listen. Reflect and make the hard things easy. Maintain focus on the outcomes and deliver the happy path that just works in a few lines of code. Set developers up for success and enable them to realize value faster and know that both they and their users are secure by default. All of this combined will play a big part in building trust and help drive that essential developer growth. We deliver over 40 identity SDKs across a multitude of languages and frameworks. Our SDKs are built for developers and with over 73 million downloads a month, I like to think we must be doing something right. That is the power of our SDKs. Before I finish, I want to say a little thank you to SDKs with a poem, as this has been part of my journey for the last six and a half years. So here is a world exclusive and owed to SDKs. In the realm of code where data reigns, a sentinel stands to secure domains or zero SDKs, their name and fame, the guardians of secrets in digital game. They dance with tokens in rhythmic prose through APIs where the data flows, a symphony of secrets encrypted and true. They shield us from chaos to privacy they bow. For in the shadows locked threats unknown with prying eyes and malicious tone, these brave protectors, they rise, they stand to guard our info across digital land. So raise your voice, sing praise and cheer for our zero SDKs, the sentinels dear. They hold the key to a world secure in the vast cyberspace their presence endures. Well, thank you for listening to my talk. I really enjoyed sharing the power of SDKs with you today. So yeah, I've got, I guess I've got a few minutes here for any questions. So if anybody has any questions here or anybody has any questions in the chat, please drop it in there. I'm happy to answer any questions about SDKs. All right, thank you.