 All right. Well, I show one o'clock so we can get this started welcome My name is Matt Raebel and this is the octa developer office hours We try to do this once a month where we basically get part of our octa developer Advocate team together to answer questions from the community as well as anything that comes in from Twitter or LinkedIn or anything real-time and so Welcome if you're here today. This is our Java specific one And so we want to just mostly entertain Java questions related to the Java ecosystems as well as security OAuth and all that kind of stuff. So we have with multiple streams going we have the zoom stream We have the YouTube stream and I'll be taking questions as they come in Repeating them here and then talking to Micah Brian or myself and getting those answered for you. So Let's begin here. I think the YouTube stream isn't quite ready yet. No Says waiting. Oh You might be going to the wrong one Because it gave me a it is live. Yeah, I see that on your screen So I'll I have this link here. I can put it into Yeah, QA maybe No, we have no questions there, but is there a chat here? The chat in the zoom you can also throw it in our slack put an internal slack. So here's That URL there that I see anyway, so I'm gonna try that one see if that's working Yeah, that's working that's good. Oh, there might be two of them out there Someone wants to log into YouTube and kill the second one. I don't know but I'll get started with the question. So The first question I have here is Asks should I use the octa spring boot starter instead of the spring security starter? So what I'm guessing this question is asking is you can actually use the the spring security starter and even some OAuth starters as well to To add OAuth security to your spring boot applications So Brian you want to take this one? Sure. So so this is this this is a it depends type of answer So you can use spring security out of the box. It'll work just fine. It works great So what our the octa starter adds is a couple things. There's a little bit of sugar as far as making it easier for configuration but there's also The fact that we validate our JWT is a little more strictly because And this goes back into some more OAuth specific things JWT validation in a OAuth Implementation isn't really perspec right just ends up being more of a convention So our spring boot starter validates some of the octa specific Claims whereas the the the generic spring security Validates just more general like this is what the industry is is doing So that's still that's still fine And also as of spring security 5.2 you can also use opaque tokens, which is that is the perspec Makes a request out to the remote IDP and then back again, and that would work the same way either one Okay, I would say it depends I have a question. Is there anything specific in our starter that would make it not work with Someone other than octa. So if you want to use like key cloak or something like that Are we doing anything octa specific? You should be able to use you should be able to mix IDPs Spring security supports you can have n number of IDPs So it should work. I haven't tried it There is a lot of guarding in the code to make sure, you know, if this is if this is an octa request Just to do the octa specific stuff at that point Okay The reason I ask that is we actually use the the spring security starters in j hipster And we allow you to talk to key cloak or octa We don't have anything, you know octa specific in there and those work just fine And my experience is if you want to maintain, you know, three or four dependencies and you know, 11 lines of yaml Instead of three dependent or one dependency in three lines, right? Then that's the difference, but it's good to hear there's other validation and and a little more security in there All right, so moving on to the next question here Should I use SAML or OAuth for my application, so let's give this one to Micah Yeah, sure the I get that question a lot and the the the best answer in the unsatisfying answer is it depends but I always like to ask Are you is the app that you're building going to have a backing API or will it have a backing API? And if you know up front that might help to to clarify so just in general SAML is a little more heavyweight It's a little more dated, but it's perfectly fine still as a standard for single sign-on What you get with open ID connect and OAuth in addition to single sign-on is you get the ability to Access backing API is on behalf of an authenticated user So for customers that that are building an app from scratch that are gonna have a backing API You can have a the same technology end-to-end if you use open ID connect and OAuth Whereas if they use SAML for the single sign-on piece SAML is just not Well suited for backing API's So you'd have to use SAML and then something else for your backing API's and that would most likely be OAuth so depending on the app that you're building and and You know, there are other considerations as well, but that's a good first line to look at is are you gonna have Backing API and at least in my experience in most cases The answer tends to be yes for modern applications because they want to they want to get an economy of scale so if you're building a new app, you're probably building a mobile app and Web app maybe a desktop app and you want to be use a be using an backing API so that you can reuse that that back-end code in all those different contexts So in most cases for most modern apps OAuth and open ID connect is gonna be a better bet and and I've even had conversations where a Customer will say well, we were a SAML shop. We already know SAML and depending on the app that they're building You know, my answer is is often well, you might be better off Taking on that learning curve now For open ID connect and OAuth and and then having the same technology end-to-end then to start building with SAML And then later on have to learn OAuth anyway to deal with your with your API So if you have a web app SAML works great, but anything else like you probably want to investigate open ID connect Yeah, so good news is hey octa supports both Hey Yeah, we have a we have a question here in chat on the YouTube channel If I want to add it to my simple JSP and servlet based web app is it possible to do so You want to jump on this one Brian? Sure, so there's definitely a couple ways to do this So it depends on whatever existing framework you're using may already support OAuth so if so you just you know read that documentation since octa is you know Just to implements the OAuth standard Like like Mike said SAML OAuth OIDC you could just use whatever client off the shelf and you don't have to use any of our specific libraries So again, that depends there are a few ways to make things easier for for legacy applications If you're not using existing security framework or framework doesn't support support you you can even use spring security In in spring boot in a non-spring app, although it's kind of kind of wrapped around things to make it even easier Yeah, and I would just like to clarify when we're talking about it in this context If we're referring back to OAuth and open ID connect everything that Brian said is is accurate but also if we're talking about the the Java SDK to work with the octa API then that you can That's just a Java library that you can drop into any Java application where it could be standalone. It could be JSP. It could be servlet So that you can use in any context. Yep, there's also a we have a specific Java off SDK, right? That's for people that are just like I want bare bones and I want to send username and passwords I don't want to do any OAuth flow dance or anything like that. So there's all kinds of options there I mean one of the easiest ones is we have a filter right a JWT Verifier filter that you can add to your servlet apps and that's just for validating jobs So if you had an angular app or react app, you know Or even a mobile app and you just want to send a JWT and you want to you know Maybe you're creating a REST API with JSP. It's not a great idea, but you could do it You could do that way as well Otherwise if it's like JSP servlets, you know and you want to actually have a JSP that serves up a login form You could do that with our sign-in widgets. So there's nothing really preventing you from getting access tokens in a regular JSP application All right, so go back to looking at our questions. I got one here Do you offer any integration with micro profile, I'll take that one since Brian took the last one that's that's very similar to the Servlet story in the sense of we have a filter JWT verifier filter that you could use or it's actually a library that you could You know write a filter around But micro profile actually has JWT support built in so there's two different components one is a what they call just a JWT authentication and that is pretty simple to use there's two properties that you specify in application that properties file and One is like the issuer URI and the other one is the keys for the Jots and so those keys will Rotate that's why there's an endpoint instead of actually downloading them into your project And so we support that we have if you Google for octa micro profile You'll find a post on how to do that and I did try There's also an open ID plugin or an OIDC plugin for micro profile And so apparently you can use this as well if you wanted authentication So the jot one that just validates tokens as they come in whereas the authentication would actually like redirect you to octa to log in and then come back and That exists. I haven't tried it But I did have a good friend point that out and be like hey if you want to do it with porcus Which is you know a micro profile framework then there is that option And what we see a lot is that typically people building, you know micro profile applications. They're building APIs They're not building web apps with templates and JSP's and stuff like that in them So Yeah, so yes answers. Yes, very cool So next question What is the difference between all the octa Java libraries? So this seems like a good one for Brian since he's written a lot of them Yeah, so so octa has a handful of libraries So server our big ones are our management SDK, which is more your your typical crud operations create users groups Applications those types of more management Functions, and then we also have our spring boot starter, which we've talked about that's more of a This is the easiest way to get to get going in the spring world with octa So the big difference there obviously is one is you know meant for a lot In your in your web app the other one could be used anywhere It could be used, you know, you could build a command line application some back end service some rest API whatever you have to do You could use that And then we also have as Matt mentioned JWT validator, which is more of a I need to plug octa's JWT validation into my Existing framework, and that's just the Java library with very few dependencies. You can just drop in and use, you know with a couple lines of code and we have a Authentication API which again Matt Matt mentioned which is more the the bare bones low level stuff Which is great for you know, if you're migrating off of some service or you're you're you're split you're splitting So, you know, you're trying to figure out if as you're migrating to a different service like octa Maybe you want them to send Octa user registrations and and logins to octa and then you still have some some other third party or homegrown Code that you want to you want to split out. So so a lot of times it's easier to do that You know it in in your Java code and it's that's also used in our Android library, which I don't do a whole lot with but You can do you can do Like a native form login like build your own form in Android and you can do a web view login And what else do we have? Oh, we also have a a hooks library that is new and up and coming to help out with if you're building Responses to octa's octa's hooks I think that I think that's that's everything. Are there any others that are like in development or upcoming or is our most in feature complete and There's not much roadmap No, so there's a lot of other things that that We're trying to work on so obviously, you know trying to improve existing libraries, right? I know Mike and I have been talking a lot about With less hazel with the founder of JGWT. So we're sort of updating that library as well so these are sort of tangent libraries as well as Supporting the new Peseto Peseto spec. So there's a lot of things like that that are on our roadmap as well And you know, I've been I've been itching to to add some some some things into spring security So it's not pasto I don't know how you say it. I just assumed it's Peseto. I think that's what I've been Every time I read it though. I'm like paste to what yeah I it's pasta Okay Let's see here um What should I use in conjunction with octa's java tools when building a spa? Micah, you've created several spas. What would you answer? Yeah, I mean the short story there is we we have libraries for all of the the popular Browser-based web frameworks so Vue.js angular React those are the big ones, right and we have Libraries for all of those so it's a slightly off topic of Java, but since spas are Kind of the mainstream you can you can use our Our libraries really and they integrate very well with the the spring boot back end and one thing that I haven't Kind of jumped into myself, but I plan on doing you know in the next couple of months is to use J hipster both with our javascript and our Java libraries and and you might have more experience with that map, but You know if I were gonna start a spa from scratch outside of J hipster I work a lot in Vue.js. I would grab you know fire up a Vue.js project drop in the octa Vue.js library Set up my spring boot back end drop in the octa spring boot starter and then I'd have you know end to end off and Be ready to build the app It's kind of a tangential question, but maybe you can answer Matt if I wanted to do the same thing in J hipster Is there a command line ready to go for that or would I fire up a J hipster With my front end of choice because I know it supports angular and Vue at least maybe react as well But can you specify octa right out of the gate or do you need to like add some stuff in after? So great question. So the question was how do you do this in J hipster? J hipster is an application generator that generates a spring boot back end There's actually dot net and no JS back ends now as well But I like the Java one because that's spring boot and I love spring boot But yeah, so what what I started doing Shortly after I started with octa was integrating octa into J hipster And it was more of a you know adding oauth to J hipster And what I discovered when I did that was that the oauth support that we had in J hipster was actually setting up like an Authorization server because spring boot actually allowed you to build an authorization server and then on the client side it was like angular code at the time because we didn't support reactor view and it was sending like and Client ID and a client secret from the front end to the back end and like getting Jots and doing all that and I was like There's you know, it's type script code not JavaScript code But eventually JavaScript that was actually having the client secret in there I was like hey, you know, I've only been here for six months But apparently this is something that you should never do right and so when I found that I was like, oh my Right because I had written a storm path plug-in when we when we're at storm path for J hipster and it was a little bit different Right because you weren't actually integrating like, you know oauth you were just adding storm path And so when I saw the oauth support was actually like doing it wrong I was like, okay, we got to you know, take this out and do it right and so It's actually been controversial and we still get people that ask, you know Why are you doing it this way? But we let the server side do everything and the reason we do that is because First of all, it makes it easier to support all the clients, right? And also J hips by default packages everything together. So even though you have an angular app, right? It's packaged in your spring boot app and even if you use the CDN and I actually, you know pulled it apart like It's still gonna have like a cookie communication between the front end and the back end So the nice thing about that is we don't have to worry about implementing it for react or for view or anything like that And it just lever just brings security and when you click on the link on the front end That's in react or viewer or whatever it redirects to the back end The back end does oauth dance and then it just returns a cookie to the client and then they can you know talk to each other So we've had people come in and be like, I want to make this stateless and therefore I want to use Jots and I want to use an OIDC library and Angular to do it that way and And I just tell him like he can but wouldn't it be more fun to not Maintain, you know authentication in your front end and just let the back end handle it So that's how we do it and the thing that we did set up, which is kind of nice is by default It's also an oauth to resource server So if you were to somehow get an oauth token in your client and pass it into the back end That would work as well. It's just not by default And so we have like an ionic generator that I wrote for Jay hipster that you can generate a PWA that uses angular and Ionic and you never even put it on a phone, right? You just put it on a browser that will actually talk to that Jay hipster back end and that Jay hipster back end will automatically parse that You know authorization header and and make that whole thing work So we just try to do it more secure way and I've had people come in and like rip it all out and do it all on the angular side And I'm like, no, this is a you know, it's good. It works But if we can be more secure and do everything on the back end then that seems a good default Yeah, that's that's a great answer and I didn't I didn't actually know that and for people on the line That's actually the best security posture to have if you have a spa app that has a backing Application server So, you know, if you have a pure spa app and it and it must have a token then then you have to Do it in the spa app But if you have a spring boot back end or some other back end The best security posture is to let the back end deal with the tokens and then just use the the the session cookie to Manage communication between the spa and the back end. So that's really awesome. I'll have to dig into that Yeah, so so before we change topics, too I do want to point out we Octa has a lot of blog posts that we talk a lot about you have a spring boot back end plus, you know X front end so I know we have few and a few different versions of angular and a few other things out there, too So if there's something specific that we didn't cover Definitely check out the blog Yep, great great advice. All right, so here's one Which JDK's is the Java SDK optimized for so as you know There's there's many Java SDKs available now and you can choose all the way from, you know Java 7 to Java 14 So I'll take this so so in my opinion, I was saying this before I call here There's really two versions of Java that people really care about as far as I'm probably gonna be ostracized for saying this but there's Java 8 Which many many of us are still on and there's Java 11 And really the big the big difference is came around Java 9, right? So there's sort of pre 8 8 and post 8 if you really think about it that way But our our libraries are built for Java 8 and we test with 8 and 11 So there are a few things like I said post post 8 starting with Java 9 there are a few different changes to some libraries and and you know some things were pulled out of the JDK so But we test with both of those versions So we assume that things with things will work going forward however, if if somebody reports some bug that you know came out with one of the The newer versions we'd probably try to look at it because it's probably still there's probably still some backwards compatible fix But like I said for the most part 8 8 and 11 are ruling the day okay, and Is there any plans to make a different baseline like Java 11 the baseline or I Would love to but I I sort of Think that the industry is gonna be stuck on 8 for a while. I mean if you look at Android There's a lot of Java development on Android. That's still not at 8. It's at 6 or 7 and that's that's Going back to even even Java 7 is is mind-numbingly Frustrating at points just because there's a lot of things to do to migrate your APIs Stably right like like default interface methods and there's a lot of little things like that in streams for is the other big one that you can't do before 8 and I Just I don't want to go back there And we should we should add is even though we test with 8 and 11 There's no reason that it shouldn't work with 9 or 14 or anything else. That's post 8, right? Absolutely, right? What about a Java modules are you using Java modules at all in our SDKs? No, so that's another thing that that has come up a couple times especially people that are that are doing You know, obviously you want to use newer versions of Java, but then with like, you know folks that are like the OSGI folks, right? So I did find a few different ways that you can support sort of, you know, Java 9 plus Modules with Java 8 you basically just compile a couple files with with Java, you know, Java 9 or 11 and And just package it all into the same jar. So that way if you have a newer JVM It can read those files and your old JVM's would just ignore them. So I have thought about doing that but It's it's not on the It's not on the top of my list So so I did hear some interesting recently Java 8 right is now ubiquitously adopted pretty much, right? There's only a few stragglers and Java 11 seems like it's having a little adoption problems, right? Like people aren't, you know, adopting it quickly And the interesting thing that I read was that Java 8 had a really long Adoption sequence it took several years and they were very worried in the beginning just like we are now at Java 11 that people Weren't gonna upgrade right and I think you know, they eventually did so just to say that, you know The situation we're experiencing now with more rapid releases and people not upgrading isn't really new It's kind of, you know, the Java ecosystem in general. Oh for sure Especially, you know, when you factor in the old, you know, J2 EE sort of, you know, that was, you know, two years behind All the other JVMs, right? So, you know All right, so you did mention Android and Java 8 And Android now uses Kotlin, right? As their first-class language or they have first-class language support And I believe part of the reason for that is, you know, maybe it's Google and Oracle and the API like copyright case and stuff like that But I don't think that Google will actually make anything above Java 8 work on Android, right? Because why would they invest in Java, right? This company over here keeps suing them every time they do So Kotlin, you know, seems like a better choice So the question here is, the reason I brought it up is, does your Okta Java SDK support Kotlin? Yes, so it's a little tricky on Android, again, because the way Kotlin works So Kotlin will compile whatever current version it can target an older JVM So if you're writing Kotlin with all the newer syntax, you can actually just target an older JVM And your classes will be compatible with the older JVM So, taking Android out of the picture, things just work, because it's all just, you know, Java bytecode and everything's beautiful So you have to be careful on Android, if you're using, if you don't support, I think it's Android 23 or 21 or I forget which version it is, that starts with the Java 1.8 support But other than that, anything Kotlin should just work with any other Java bytecode out of the box So there's nothing specific you need to do for Kotlin to work with any of our libraries? Nope Okay Cool All right Let's see here Since we're talking about the JDK and newer versions, does the Java SDK work with Java 9 and beyond? Like, is there any issues there? Nope, so as mentioned before, we test with 8 and 11 So there was definitely a few issues that I found pretty much every project that I've ever worked on Switching from, you know, going migrating up from 8 But it's all like, you know, XML parsing libraries you have to add back in Or there's a lot of Maven plugins that are sort of third-party Maven plugins that sort of don't work great with newer JVM So there's a lot of tweaking you have to do there, and I assume Gradle's the same way But that's mostly because those plugin providers haven't updated yet And if I'm remembering right, even Maven itself, I think, is targeting Java 1.7 And there's been talk in that community to at least get to 8 because nobody wants to deal with all the code anymore Right, so while we're speaking of, you know, versions in Java, I remember that our Spring Boot starter Between Spring Boot 2.1 and 2.2, we had to have some changes in there, right? It was like, we had our starter 1.2.2 and then 1.3.0 is for Spring Boot 2.2 Do you remember what changed between Spring 2.1 and 2.2? Yeah, I forget the class exactly, but we were depending on, you know, fairly low-level stuff, right? Because we're sort of really close to the Spring Security layer Most applications operate a few layers above, which is great because, you know, if you can push all that stuff into some framework And not worry about it, that's way better So one of the classes that we were compiling against changed in a backwards and compatible way So it was source-compatible but not binary compatible So it took me a little while to find because the code compiled, you know, in the old version and the new version just fine But if you had an old binary, it wouldn't work with a new binary So it was a minor breaking change in Spring Security that we had to update to Okay, so in that case, it was something like a runtime error, right? Yep, yep Okay, because I did an upgrade for Spring Security, Spring Boot in J-Hipster, we migrated to 2.2 just a few weeks ago And the reason for that was we waited till Spring Cloud came out and that was, you know, lagging a couple months behind Spring Boot And what I found was that doing a granted authorities mapper and using Spring Security 5.2, I guess it was It would return a different class for scopes. It used to just return roles and now it returns like scopes as well So I think, you know, that's something that they changed. I think our starter was always doing that, right? You had some code custom logic to do that Yep So I just had to do an instance of but that's because in J-Hipster we're not, you know, using our starter So maybe we should have less code, right, you know Nice Alright, so we got one from YouTube here Why should I choose Octa Spring Boot Starter instead of Spring Security OAuth 2 Auto Configure? So I can take this one because I've spent a lot of time with OAuth 2 Auto Configure and I think even Micah's written a blog post on this So let me know if you want to jump in. I'll just do a quick answer here, Micah The reason that I would say is with the Spring Security OAuth 2 Auto Configure, there's annotations like Enable OAuth 2 SSO or something like that and Enable Resource Service so the annotations you can use Spring Security basically deprecated those and said Spring Boot gave us those. Those aren't really our annotations but we'll continue to support them And we'll go ahead and make it so you can do the configuration of OAuth whether it's OAuth 2 SSO or it's Enable Resource Service, we're going to do that as part of the Spring Security DSL Do you have anything to add on top of that Micah? Yeah, I think the only other thing and it's really just kind of a convenience is you don't need as many configuration properties if you use the Octa Spring Boot Starter I forget exactly which other ones you need. If you don't use the Octa Spring Boot Starter, Brian may know but with the Octa Spring Boot Starter you just need the issuer and the client ID and client secret and that's it Right and so I use, we don't use the Spring Security OAuth 2 Auto Configure in J-Hipster, we just use the raw I think it's Spring Security OAuth 2 client and OAuth 2 Resource Server now they're separate dependencies and yeah the configuration is you know it's that much Right, but I do want to stress what Matt said, the big thing to me would be especially with the OAuth 2 Auto Configure is it's a deprecate library so that whole OAuth project used to be separate outside of Spring Security And then was it Spring Security 5.1 or 5.0 that was all moved inside of the project so now it's no longer a redheaded stepchild or however you want And you know the interesting thing that happened with the Spring Security project recently was they announced I think a month ago that they were no longer going to allow you to build a spring or just an OAuth 2 authorization server with Spring Security they were like you know it's been possible in the past But we're not really in the product business and we'd rather just develop libraries and the response on their blog post was so fervent that people were like you know no no like we use this and stuff and so I think they actually had to reconsider and now they're like Oh wow We might change things around and there's so many people that appear to be using this that I think we'll still do it Yeah I mean you know I work at Oxford I have a biased opinion but I definitely think if you don't have to host your own IDP you probably shouldn't, right? And I think part of it was they were in that blog post saying you know if you want an open source you know authorization server just use Keynote, right? Yep You know you can run it in a Docker container and that's what we used for Jay Hipster and it's awesome but I think people are saying like yeah that's great but you know with Spring Security you can do it in 50 lines of code, right? So why do I want to download this open source project when I can do it you know with Spring Security so I can see both sides but I like you you know try not to let friends write their own authorization servers Exactly Alright so we have one from YouTube here. What are your thoughts on using Pixie, P-K-C-E code flow instead of off code flow in back-end libraries like Java.net and so our resident Pixie expert here Micah you want to take that one? Yeah sure and this is actually something I recently learned myself because I've only ever used Pixie on spa type apps but it turns out there is an advantage and that is in a context where you already have a client ID and a client secret like you typically would on a back-end app like Spring Boot there's still an advantage to using Pixie in conjunction with that and that is for CSRF that the code verifier and the code challenge are only used once even though you're still using the client ID, the fixed client ID and secret and so you really get the benefit of both worlds you get the benefit of the regular authorization code flow which is authenticating the client to the server so authenticating your Spring Boot app to say Okta that's the benefit of the fixed client secret there but you also get the benefit of the dynamic secret in the code verifier and the code challenge from Pixie and that's very useful for things like CSRF it'll only occur once and you can validate that value as an extra check and you can guard against things like replay attacks or access RF type of attacks from external sources so I haven't personally done an example with Pixie on the back end yet it's something I have on my to-do list now that I've learned this new information but we spoke with a colleague of ours who contributes to the standards body and it's kind of a subtle use case but one that is valuable so both authorization code flow and authorization code flow with Pixie all at once so you're still using the client secret and you're also using the code verifier and the code challenge Alright thank you Alright so here's one if I have an existing Java app that uses a different OAuth provider what do I need to do to use Okta instead Anyone want to take this one I'll try to jump into that one so assuming using a library that supports OAuth it should just be configuration that depends on how you're using that library and if you're doing anything sort of IDP specific but if you're just using some library I know if you switch between say Google or Facebook and Okta with Spring Security it's just configuration changes everything else just works Spring Security or again other frameworks are smart enough to know to go to redirect to a different IDP and you come back and your application code is still the same And I think from what I've seen just in the Java library space a lot of times it depends on whether your library like supports OpenID Connect or just OAuth because with just OAuth you might have to specify a number of different endpoints for you know authorization for the token for the introspection all that And with OpenID Connect you just talk to a single endpoint what's called an issuer and then it downloads a document that has all that information in it So that might be a difference whereas Okta you know my less configuration with another service you might have more Yep and there's also so if you're migrating off of one right and you're still have users on the other one Okta does provide some some options for you to do that too that we probably don't need to go in here but There's definitely some some other options where we can help you migrate from one IDP to another and still not have any downtime Okay cool so I got one here that I think we've kind of answered but how do I use Okta and Java apps that don't use Spring So good maybe segue here would be what about like a Java FX app because that's a Java app that certainly probably doesn't use Spring How would you do it there So Java FX is a little tricky right because it's a again it's a it's client code and I haven't really used Java on the desktop since the days of swing and I used to love writing swing code If you remember that Yeah I loved it everything was the same you know it was before sort of the web 2.0 where everything was styled a certain way but no you could literally follow document You don't have to be artsy and creative that was that was my sweet spot right there So I know I know at least for Java FX I've seen a couple of libraries I assume they they open up a browser and then redirect back so the way I've seen this done is very similar to again a mobile client Sorry you fire off a browser you know you go do the The OAuth login maybe you have a second factor and then that application will redirect back to to your desktop application and on on a mobile device you know ends up being in the URL I know Mac supports it I assume Linux and Windows support support that as well and then you have some sort of inbound hook in your desktop app to handle you know validating the the remaining piece so I know there are a couple libraries to do that I haven't played with any of them But it's all very possible. I have played with some command line options. So there's a couple OAuth flows that will really help out with that I know like there's a device code flow Which you know is what you use when you log into Netflix or or Amazon or not Amazon sorry yeah Amazon Prime from your TV you know you go to some other machine you type in the code those types of flows obviously that's not really great for a Java FX app but if you're building like I said a command line app that type of flow could work for you. Right. So we do have a I remembered because I helped edit the article there is a tutorial that we have so if you Google for Java FX octa it comes up with this blog post about how to build a Java FX desktop app with OIDC and octa and I believe if I remember correctly that uses a library from Microsoft But it only works with Java one eight and only oracles Java one eight because that's the only version of SDK or open JDK or anything that actually has Java FX in it. So since then I think with Java FX 11 or open JDK 11 it's a separate project. Right and it doesn't work with that library but there's also this company called glue on that's really taken a leadership role in Java FX and made it so it works on like Android and iOS and everything so In that case what I would say is you could probably use our off SDK which would mean building your own login form in Java FX and then talking to our off API directly right the only problem is you're not using standards like OIDC and open ID connect but a lot of times on the phones. You have to actually pop a browser and redirect and some people building those mobile apps don't want to give developers those that are consumers that experience right they want to be able to use name password and you know face ID and make all that work so you know couple options there. Yeah one thing I would add to that also is it's kind of outside the question of our specific SDKs but once you are using a standard like open ID connects something like Java FX would be really the perfect use case for pixie. And then it just becomes an exchange like Brian said with a capturing the result of a of a browser and exchanging an authorization code for a set of tokens. So although it's kind of outside the realm of our SDK specifically it's pretty easy to accomplish. And we have a couple of examples that I'll post in the chat on the the YouTube live stream. And Brian also mentioned the the code flow or the device flow. And if you're not familiar with that we have a good blog post on that. So I'll paste both of those into the YouTube chat I just pasted the the the device flow one. So that's how you can add the device flow to any application using octa. So it's not specifically our Java SDKs in that case but it is kind of an approach that's aligned with the standards and since octa supports those standards you can use octa directly with in those sort of context. Cool. All right so we got another question on how to add Android authentication so I'm going to share my screen here and just show you some examples last time I tried to do this I couldn't figure it out but hopefully it won't be that hard this time. Here we go this is a if you look at the URL there it's octa slash samples Android. And so if you have an Android app and you want to add octa for authentication. There's a number of different examples here there's a browser sign in right which pops a web browser does redirect dance just like you've experienced in a normal browser. Whenever you log in with any social account very similar to that looks and acts the same. Then there's this custom sign in here that is a little more customizable this would be like if you're doing Java FX and you just want to you know use our API. But this also has like multi factor authentication using either you know SMS or a phone call or Google Authenticator even our product called Octa verify which is really nice to use. And I believe there's even Web Authent support so obviously in Android it would be different because Web Authent is from the browser. But then there's even a sign in with Kotlin here and to a tp generator as well so all those are available for Android to answer that question and then I'll add that repo into the YouTube chat as well man. Okay. So now I got to figure out how to stop sharing new share stop share there we go. Okay. All right. So that answers a question about Android. Here's one. Why should I use the Java SDK and not a Java HTTP client to make direct API calls. So I believe this is in reference to the fact that Octa has a rest API that if you know you want to construct your own code to just call that directly you can when we all started here we came from a company called storm path. This is almost three. I think it'll be three years ago. And Octa had a rest API and that was most of what they provided for developers and we came from storm path and storm path. We took a different approach we had a rest API but we also developed all these specific SDKs for the various languages. And what we found was developers loved it right in the sense of you know figuring out a rest API doc and figuring out how to do HTTP client versus you know actually just learning the API for Java code developers loved it. And so why should you use the Java SDK. Well because you like Java and you know you don't like figuring out endpoints and reading rest endpoint documentation that's that would be my case but Brian you've written the job SDK so why would you recommend that people use it or what advantages are there over talking directly to the API. Yeah so I mean it's definitely you know a Java preference versus going to figure out you know the rest API you know parsing parsing the response you know serializing obviously there are libraries out there they'll do that for you right. What is it spring springs rest template or whatever it's called now. What's that the web client the reactive. Yes yes that yep the web client so a lot of that can be done for you so for for simple requests maybe maybe maybe that's your you know the the three minute option or the right. But if you're doing anything serious you probably want to use a library that's sort of dedicated towards that right so you don't have to go write anything you don't have to create wrapper objects you don't have to do all of this song and dance because somebody's done that for you. Plus you know the SDK adds caching. It does retries. You can configure how you respond to to to request throttling right so maybe you want to retry the request five times maybe you want to do X times within within two minutes right so if you have a sort of a back in service and you could throttle that really slowly that's going to do that if you have a if you have a user user faced service where you need to respond you know within a small period of time maybe you want to want to retry once so so you could do a lot of those things. All that's built in for you so you don't have to write it. So that's that's my big pitch. I have a jet pointed out on YouTube that error handling and rate limiting is included in the Java SDK which is important. And just to piggyback on what Brian was saying on the caching layer, the cash that's built into the SDK is a production ready cash. You're in a single JVM environment, but it's also pluggable, meaning that if you are in a multi JVM environment you have some sort of distributed environment load balance or whatever, you can drop in. Redis or Hazel cast or you know something else to use as a caching layer, and it'll just plug into the Java SDK so that's another wheel you don't have to reinvent. You wanted to go on your own. Yep, so also with that so our SDK is not specific to spring right doesn't have any spring dependencies but we do have the option if you drop that in with one of our spring starter or use the SDK spring integration that will configure the SDK to use spring cash so whatever whatever spring cash implementation you're using would just work with the SDK as well. And then some code that uses our octa Java SDK in a spring boot app and I remember all I had to do is generate like a token right and then put that in my properties file and then actually just inject a client into the constructor right is that typically all you have to do. Yep. And then you know it was like list users are called user by an email and even by the principal I think you could just pass that in directly Java security principal and get, you know, you're talking to talk to. So that's pretty cool. So that talking about API keys, putting in application properties file API keys kind of like secrets are not to be stored in source control, especially if it's in a public repo so question here is what is the best practice for storing the octa API key for use with the Java SDK. So, sort of a future hint right so for applications that are using OAuth access tokens in the future, hopefully near future will be able to use the access token instead of an API key so you can manage that same request flow from whatever you know in the scope of that user. So right now the SDK works with an API key, you know which would either be global to your application or however you have that that configured. One of the best ways is probably using something like like vault or some other secure storage to get that the key into your application. So obviously definitely not system properties, unless you're injecting system properties some other way, like a Java agent or something that's not on the command lines the big issue is, but in the command line you can get, you can get the, you can run like a PS and see the arguments. You can use environment variables obviously again that's, that's not a that's definitely better than putting on the command line, but it's also still, you know, every every fork, every fork process or anything still has access to that. Those environment variables. So something like vault or some other secure secure storage would definitely be the way to go. So when you say vault, I've heard a spring vault and I've heard a hash a corp vault or using a generic term for vault. Yeah, so vault so hashy corp vaults of spring vault can access hashy corp vaults and and deal with all the leasing and the complexities of of hashy corp's vault for you. And there's a great little tutorial. I think I think it's even in a GitHub read me from the spring vault project, which, which basically just downloads like a single binary from from hashy corp starts it up tells you how to like, you know, the, the five minute overview of this is how you run a vault server and then you can play with it that way. So I would definitely check that out. I haven't seen it. And if you have if you have some other way to store secrets that you know that's fine too. Right and I think one of our coworkers Randall always talks about some AWS service that yeah KMS. Yep. Yeah we use we use KMS quite a lot in internally and that's a good place to store something like sensitive API keys as well and the, the, this is outside of octa but the go live the Java libraries to deal with KMS are pretty straightforward and easy to use. Is there a, is there a spring spring config spring cloud config plug into use KMS. I don't know, I bet there is, but I was going to say I'm guessing there is inquiring minds want to know. All right, so there's another question here. Can any of your SDKs be used for newer frameworks like micronaut and corpus. Yeah, so all of our SDKs except for the spring spring libraries, of course, are, are, you know, framework agnostic, right so the spring one obviously because it's integrating with spring security, but everything else. There's no there's no framework, there's no serious framework dependencies. So we have a JWT library that uses JJWT that sort of implementation details and that's again a very small, small library with very few transitive dependencies so we really, really try to not not include a lot of bloat in our, in our libraries so there's a lot of great libraries out there, like, like commons, you know apache commons, guava and a few of those other libraries that have sort of historically had version problems. So when you switch between versions and then, you know, transitive dependency hell. So we sort of take take the approach of avoid those when possible. And again, I don't have anything against those libraries is great if I was building an application today. I would do that. I would use those libraries but maybe not with a framework. And you know I haven't played with it myself yet, but my understanding is that micronaut runs on top of spring boot. So I'm wondering if we couldn't just drop in our spring boot starter and still have it work with micronaut. Well, while Brian was was answering I went and googled a bit and if you Google for micronaut octa. They actually have a guide for securing a micronaut app with octa. Kind of different from our question our question was, you know, the Java SDKs, right, how can you use those micronaut. And so this is a little bit different because the Java SDK is what you talk to our user management API to manager users and apps and things like that, versus just securing an app so as far as I understand it, they support a lot too. Since they support a lot too, we do too and it works and this guide here looks pretty nice on how to set everything up and it's a lot of us just setting the callback URLs and, you know, configuring on octa and then they have a nice long application dot yaml file that's the second gotta be 15 lines long so it's almost like spring security right with all their configuration because really there's, you know, 15 lines here but there's only three properties that you're really entering so that's yaml for you right. That's really interesting I'm going to circle back and see if we can't drop in our spring boot starter and reduce the nut that that config. Or make it smart right because their property names are different right instead of spring security a lot too it's like micronaut security a lot too so there might be some things we could we could do to make that work that would be. Yeah, I mean that's one of the big things our starter does right just takes some simplistic properties and remaps them to the spring standard ones. Right and for this one it's got, I think, you know, it's those three properties but then it's enabling a bunch of other stuff like a lot to and, you know, JWT and log out and all that so it's just adding a bunch of true places so that might be interesting but I'm personal fan of micronaut and I have meant to write a blog post on it. I just haven't got a chance. I did publish new one on spring group 2.2 using Kotlin and angular yesterday so that one's out there. But as far as corkis if you Google for corkis octa. There we are on the top with how to develop a corkis act or app with Java and OIDC and so as far as I know that one is developing a resource server. So it would be just an API rest API, most likely that you would talk to it from some other client. And like I said if you did want to do where your back end actually requires you know redirect to octa for login. There is an OIDC plugin as far as I know for corkis that should work. I haven't tried it myself but if you are interested, please try it get back to me if it doesn't work. We'll make it work. That's what we do here. I posted both of those links you just mentioned in the the YouTube chat. Okay. So the last question that I see here and we only got a few minutes so this will be the last one is when should I use the octa Java SDK instead of the octa spring boot start. I hear this question a lot and I sort of touched on this a little bit earlier, and it's not even just the Java side we get this similar question for for dot net. And I even asked the question because you know if I'm unfamiliar with dot net, you know the terms and how things are named over there are different. This actually comes down to on the Java side. The Java SDK is is your management tasks so it's interacting with our rest API. So if you want to create users groups you want to get additional user data, you know maybe you have a user ID and you need to pull in other user information update that user, you know do something. You would use the SDK or if you're automating some tasks right like if you're, you're writing some code for some CI related thing or integration testing or whatever you could use the SDK to set up some some structures or whatever. And then you would use the spring would start or just for authentication. Okay. That makes sense. Alright, so you got a minute or two left any of you want to have any parting thoughts on Java or what's what's your big goal for that for the year what are you excited about me personally. Yep. Well it's like one of those few years where the bus is done right so I don't have to worry about like that was in your goal so I'm happy but beyond that I think I think continue to play with a lot of the the new framework stuff out there right I'm always been a big Java frameworks fan so spring boot, corkis and micronaut digging into those a little bit I've started to write a lot more Kotlin code and I like it. I like how Intel J makes it very easy for you to just copy and paste your Java code and then it becomes Kotlin so it's a nice learning curve. And beyond that, probably, you know, maybe write some, maybe try to write a Java FX app on a mobile phone and see if that's as good as the people that are developing it say it is. Right, but I'm excited about Java like, you know, Java 14 is coming out next month and no one will upgrade but, you know, as developer advocates we always get to try the latest stuff and don't have to worry about production as much. So it's a nice, it's a nice role to have. Nice, nice. Yeah, I'm really excited about about Kotlin too so should be good year. Yeah, I got three for this year Kotlin, micronaut and Jay hipster. I'm long overdue on getting hip to Jay hipster. Well, and I've been working on the law to support for reactive Jay hipster so that's become awesome week or two. All right, well, thanks to all those who showed up and we'll go ahead and end this and see you next time. Bye everyone.