 and welcome back to the Workforce Identity Developer podcast from Okta. Today, I'm joined by Laura Rodriguez and Elisa Duncan. Welcome to the show. Hello. Hello. Today, we're going to be talking about the SDKs that we have at Okta. And Laura is a staff SDK engineer here. So, Laura, what does an SDK engineer at Okta do? Our team basically takes care of SDKs and other developer tools. And we are also very involved in the API design. So, what we do is basically, we do, we review the API designs that other teams propose. We provide a lot of feedback because we have like an overall view of all the APIs since they all end up into any of our SDKs. We also build SDKs and CLIs and other tools. We interact with people on GitHub, take care of like requests, issues, etc. And also internally, we have our roadmap. We have also close communication with customer support. So, we basically have many different things to work on. During like a sprint, that's more or less what we take care of. And Elisa is a staff developer advocate in workforce identity. Elisa, what do we do in advocacy and how does that tie in with the SDKs? Sure, yes. I use the SDKs that Laura writes and try them in different applications. Build them out, make sure that the developers using Okta have a really good experience when they use it within their application. So, the developer advocacy team are the first line feedback providers to the SDK team on using the SDKs. Some listeners have used SDKs a bunch. Others might have just heard the buzzword. And Elisa, how would a developer use the API if they didn't have an SDK available? Right, so that could be a pretty involved process. You'd have to figure out the APIs that are available and all the different parameters that you'd have to pass in. If you were trying to do a authentication using OIDC, that could be multiple calls in there. You could do that within your application or through a HTTP tool such as like Hopscotch or Postman. But there's different ways you could do it or you could maybe go the easy route, right? And if you've written code that's hitting the API directly, any change to that API is also going to break your code. So, Laura, how does the SDK improve this process? Elisa mentioned you can go the hard way and write a wrapper yourself or you can use our SDKs. So, basically our SDKs, of course, they basically are a wrapper to the APIs, but we also provide additional features and we all take care of breaking changes. We use semantic versions. So, if you pay attention to the version, to the releases that we do, you can have an idea of like if upgrading will break your code or not. And also, you don't have to worry about vulnerable dependencies because we take care of that plus additional features. So, an SDK is more than just an API wrapper and it has some convenience for developers. So, Laura, why do we need so many SDKs for so many different platforms and even frameworks? Because each language has its own idiomatic features and what we try to do is just to provide an SDK for all the testers. We have different developers' communities that we provide SDKs and SDKs are different between them and also, if you're a frontend developer, you might need different features as a backend developer because it's a totally different developer experience. So, we try to build SDKs idiomatic to the specific language, to the specific ecosystem. For example, we have the .NET SDK, the Java SDK, we also have the Node SDK. So, each of those libraries try to be idiomatic again to the language, to the ecosystem and follow the guidance for that specific environment, I would say. Yeah, so, it's like the SDK will help you use that language or frameworks best practices and more seamlessly integrate with all the features that the Octa API gives you. Right. So, Laura, how do we build the SDKs? All those different ones? Yes. So, we have different ways to build SDKs. So, for example, for the management SDK, we use code generators. We do have an open API specification for the management APIs. So, that facilitates the release process because we have a code generator that in a few minutes, you just have an SDK in specific language or even like CLIs. But then we have other type of SDKs where we do not have an open API specification or where the feature that we provide requires many or different calls. One example of that is the ASP.NET SDK, which is basically a framework integration with ASP.NET. And the idea is that you can use that in any of your ASP.NET applications and you just plug in Octa seamlessly. For that case, since it's a framework integration, we don't use code generators. So, we do that work manually. So, yeah, we have different ways. Code generators, it's the easiest one. But we also do depending on the tools or the SDKs, we might decide one approach or the other. Do we put all of the API features into every SDK or do you need to curate them based on some constraints? Yes. So, first, we have categories for our APIs because we think of APIs as a set to fulfill certain personas, I would say. So, first, we have kind of a category for them. That basically, for example, for management APIs, we have the management SDK. For people that want to add authentication to their applications, we provide OIDC SDKs. And for ID admins or DevOps, we provide CLI tools. So, we have a category for that. And then deciding when a feature should be included or not, it's based on customer request, popularity of the request on GitHub and also how that feature would simplify the developer experience of that particular tool or SDK. That's a lot to think about. I know you work a lot with .NET, right? And one of the things that we encountered when I was working on .NET was .NET versus .NET Core. And now, of course, it's now back to .NET. How did you handle that sort of mediation, even within the same framework, the same language even within the SDKs? Yeah, that's a nice question because that work was very challenging. There are .NET has been evolving a lot these years, and we have to keep up with that. And we have the ASP.NET SDK, and we provide two different versions of the same SDK. One for .NET framework and another one for .NET Core slash .NET, right? Working with .NET Core was seamlessly, I would say, because there's a lot of information and how to implement certain features and how to use the API, but it's not the same case for .NET framework because it's kind of legacy. And we still have a lot of people that are using .NET framework. So we needed to work hard to kind of provide parity in both of our SDKs. So that was very challenging because features or certain things that were very easy to implement in .NET Core was a nightmare in .NET framework. But still we wanted to provide the same developer experience for both groups of developers, .NET framework and .NET Core. So that was challenging for .NET framework to try to port the same features from .NET Core. I had to dig into the Microsoft, the ASP.NET repo, dig into the code to learn how to implement specific feature that was extremely easy in .NET Core. But yeah, you have those kind of things, and this might keep happening because .NET is still evolving. So big things happen all the time, and you need to do the work for the customers. Yeah, so we can make it look like, oh, it's kind of the same thing to use the SDK, whereas it's a very, very different thing, and you're really putting in that work to hide those complexities. Thank you for doing that also. It makes such a difference. And you also mentioned doing a lot of work with GitHub. So is that just to publish a source so folks can look at it? Or do you invite contributions from the community to the SDKs? Yes, we love open source. My team uses a lot of open source projects as well. So we really love the open source community, and definitely love contributions. We have a lot of contributions all the time. And yes, we definitely our SDKs, our CLIs are much better because of the community's feedback. So a contribution can be a pull request, or maybe a suggestion to do something better. We have a different type of issues on GitHub, not only bugs or feature requests, but many, many suggestions or peers as well. And we love that. So definitely, yeah, contributions are welcome. And we have a lot of open source repos across Okta. Alisa, do you have any advice to someone who might be thinking about contributing? Yeah, I think it might sound a little scary to contribute to open source, and especially to a large company like Okta. But the SDK engineers in their work with here are really, really nice. They're really friendly. So I'd recommend opening up an issue or starting a conversation. This is something I want to do. And just get that conversation rolling, that feedback with going. There might be reasons why they don't have that particular feature in the SDK in the first place. So it's good to know before you do all this work up front. So I think just having that conversation, just the SDK teams are so sweet. It's a great time to learn more about what, how you might be able to contribute from them too. Opening up an issue. Yeah, for sure. Because there's sometimes a lot of context. Maybe there's something that's planned that hasn't been announced yet that affects whether something's being invested in. Maybe there's some constraint that you might not have thought of because it doesn't affect your use case. But it's a major consideration for other users that there might sometimes a feature might not be there because it just hasn't been prioritized yet. But other times adding the feature might cause some challenges elsewhere. So talking it through first is always worthwhile. We love talking to people. And Laura, has that community feedback and involvement ever given you really surprising new information, things that you wouldn't have guessed without it? We get a lot of feedback on GitHub all the time. And I was surprised by one specific, I just came to my mind. This particular feature for our ASP.NET SDK. So basically when we shipped the SDK, the original SDK, we thought providing an SDK for the very basic scenario where a developer that don't want to deal with OIDC just want to plug Octa into their ASP.NET applications. So it wasn't very flexible because in our mind, the idea was to solve everything internally so developers don't have to deal with OIDC at all. But then we noticed that on GitHub many, many people started to request certain flexibility to expose certain OIDC events. So they could, for example, add custom claims to the tokens or things like that. So that was a very popular request. And we also discovered that, hey, so this SDK is not only being used by very basic scenarios, but it seems that people are using it for much more advanced scenarios. So that was a good discovery point, I would say. And thanks to that popularity of that particular request on GitHub, we decided to make our SDKs more flexible and exposed OIDC events so they can just extend the logic as much as they can. That's a really interesting story too because you might assume, oh, people want it simplified as far as it can be, but also the SDKs add some value and utility, even when you're doing the pretty complicated stuff with how they're able to elide those API changes and some of that complexity even when you're doing really advanced OIDC. Alisa, I know that you've had a chance to chat with a lot of octa users lately about what they're building on top of our SDKs. What are some things that you see people using the SDKs for? Yes, of course, and there's the standard authentication that you might expect, but then there's also things like building a custom admin dashboard with using just a subset of the APIs and features that is exposed in the octa org dashboard. So there might be reasons to have a smaller subset, perhaps for a specific customer or tenant or something. However, you have it set up and people are finding different ways to really tweak it to the next level themselves. Is that the kind of usage you expected, Laura, when you started working on the... No. Yeah, actually, yeah. I was surprised when Alisa mentioned this particular way of usage, but yeah, sometimes we deliver an SDK thinking like certain use cases, and then we discover that there are other much more complex scenarios or other customer needs. And then we keep evolving from where we started. And that's why I love GitHub, because that's our direct contact with real developers. And also, yeah, from developer advocacy, we get a lot of feedback as well. But yeah, sometimes developers surprise you with how they use our SDKs and tools. It's such a constructive conversation, too, rather than just asking, what would you like to build? You hand someone a tool that does what you thought they'd want and ask them, does this do all of what you want? And very often, that will almost, I think, get them brainstorming about what else they could build. Like, I know I think very differently when I see a tools list of features and I go, oh, but it wouldn't be that hard to just do this a little bit further. Definitely, yeah. I also had a few questions about you as an engineer as well, because to build these SDKs in all these different languages, you're kind of just having to pick up languages when we need a new SDK in them, aren't you? How do you do that? Do you have any tips on what works well for you to just self-teach a language so you can build exemplary code in it? I would say that my team, it's very unique, because we have to work with different languages, right? So first, I do code reviews for projects that are written in different languages. So that's a good point to kind of see similarities or differences with .NET, which is like the language or the ecosystem that I work with. But then I also noticed that hackathons are an excellent way to catch up with a new language and in a very time box manner. So yeah, the last two years, I participated in the Octahackathons and I was working with Golang. And it was like a short time, but it was enough to get a sense of how, you know, what features you like of language, what's missing based on what you are used to. So hackathons are a good way. And then I love to read technical blog posts and also books. I'm a book reader, so definitely books are another way to keep learning. SDKs are just that extra level of challenge beyond a hackathon project, because a hackathon is like, let's just drop our standards until we can ship it and it's a really good way to get your hands dirty. But then the SDK is saying, this is done the right way for this language. So how do you go about taking that next step to having the confidence that you're writing the language as it's meant to be written? Yeah, that's a good question. So basically, first I'm a developer. So I am used to certain practices right in my personal projects or from my previous experience. And then I'm an SDK developer, right? So many things that I usually take into account, many features are because I use them all the time. But then when I'm not very sure about what the best way to provide a feature is, sometimes I just check on other open source ribos that I respect so much what practices, what are the practices that they follow and also like official guidelines for the specific ecosystem that I'm working on. Yeah, and then of course, when we release a feature, we try to think a lot about the developer experience, but also for us it's an opportunity to release that and expose it on GitHub and get feedback from the community. So that helps too. Alisa, I know that you do a lot of code examples. Do you have any other hints about picking up a new SDK as a user? Sure, it's similar to Laura for first and foremost the developer, right? So I like to get my hands on something, try it out, learn it. Play with it. The learning is uncomfortable always, but it's always so gratifying to see it all come to completion. I like looking at actual code samples from other places, including from the SDK team, because they do have some out there in the GitHub repo. It's just kind of playing around with it and being able to ask questions. Just like I try to put myself in the perspective of developers also trying to use Okta for the first time, right? So I look on the Dev Forum. I look at different places to try to see how would I go about doing this and try to separate it from how do I learn this particular language, which might be a whole first step, then on top of that is then how do I use Okta? Luckily, my internal contacts, the SDK team as well as the developer support team here, are really, really helpful to help guide me along as well. And you really don't have to start perfect at a language to start using it. You can just go for it and it will yell at you if you tried to do something impossible. And I think that is a hurdle that some people who are getting into development might really struggle with. Oh, yes, for sure. I think you're both proof that you can just do it. You can just pick up a language and go. So Laura, looking toward the future, are there any changes that are coming up in the world of our SDKs that you're really looking forward to? Anything that we should be keeping an eye out for releases of over the next little while? So now we are not only building SDKs. We're also exploring new use cases for our customers. So we are building tools, CLIs. So yeah, the future, we hope to release new CLIs to keep making our customers happy. So stay tuned for that. Absolutely. And I also hear rumor that your team is getting to work even more closely with our Terraform team. And I'll be going into some more detail on Terraform in future podcasts. But as an ops person, I'm especially excited about that seamless integration for managing your identity infrastructure as infrastructure, infrastructure, as well as seamlessly fitting your identity in with your code the way the SDKs facilitate. As we wrap up, what are both your thoughts on how someone should get started with our SDKs? So we have open source repos. So you can take a look at our contributing guides where we have a brief explanation of how to get started. There are some also code of conduct that you should follow. And then just go ahead, don't be shy, file an issue. And yeah, or just take a look at previous issues that were posted and how they were fixed, why they were closed or things like that. But yeah, I mean, just looking at the readme and the contributing guide should be enough for you to get started. Yeah. Let's say on top of that, on top of all of the repos that's in the octa GitHub org, that houses SDK and the official samples, there's also extra samples and tutorials from the deputy team using the SDKs as well. And that's in a couple of different places to be honest. So I'm really excited that we're going to try to create a developer blog post about where we can find all these resources, try to consolidate it. Because there can be a lot, there's a lot of GitHub orgs out there with the word octa, though we'll try to help demystify some of that as well. As a user, I've noticed that very often the samples that live with the SDK are also a test case for that SDK. So if you really want to see it being put through its paces, the samples that live close to it are where to look. Whereas if you want a very pared down, less comprehensive, that may be an easier start, then an example showing off just one or two features that lives further away from the code might have been more demonstrating it at a single moment might be an easier start for you. So lots of different options to get involved with the SDKs and to stop having to use the API directly if you felt like you had to do that before. So we've got all these options. And as always, we'll have a comments thread on this podcast on the developer forum linked from the description where you found the podcast. And we'd love to hear your thoughts about it. So thank you both so much for joining me today. Thank you. Have a great day. Thank you. Bye bye.