 Hello Java developers! My name is Matt Raebel and today I'd like to show you how to build Java microservices with Spring Boot and Spring Cloud. Let's giddy up! This screencast is based on a blog post that I wrote called Java microservices with Spring Boot and Spring Cloud. If you scroll down past the beginning, you'll see there's a github repo at Octadev, A0, Java microservices examples, and a git clone command. We're going to start with that. We'll do this in our downloads directories. Once that's done, we'll open it up in IntelliJ and I'm going to open up the webflux example. The configuration that we're going to do to make it work with A0 will also work with the MVC example. This readme breaks down how to actually get everything up and running. The API gateway talks to a backend car microservice that just returns a list of cars. Then the API gateway filters out the cars that aren't cool and returns those as another list. There's two different APIs in play and we're going to use OAuth to protect both of them. With A0 CLI, which I already have installed, you can run A0 login, authenticate as a user. It'll prompt you for consent for all the things that the CLI can do with your tenant. Then you're all set there. It's all hooked up with your tenant. Also, just to show you, I have Java 21 installed. You don't need Java 21 to work with Spring Boot 3.2, which is what I'm using, but you do need 17. I just wanted to show you that I am using the latest one there. The first thing I'll do is create OIDC app on A0. Go into the webflux directory here and run A0 apps create. We're going to call it kickass cars, microservice for cool cars. Just a regular web app has callback URL that's standard for the Octa Spring Boot starter and the logout URL to logout. Then we're going to copy the issuer of the client ID and the client secret and the audience into a .env file. If you look at the API directory, there's already an example one here. We can just copy that one, paste it, chop off the .example. The issuer is right up here and the client ID and the client secret. Then rather than specifying the same issuer twice, we can just go here and do it like that. Now we can start the Eureka server, which is just a basic Spring Boot app with enable Eureka server on the main class. Go into discovery service, clear that and gradle boot run. You can also do boot run lowercase, works fine. Then in the car service, we're going to need the issuer and the audience as well. Copy this one, paste it back to here, grab the issuer and start up the car service. Then finally the API gateway. Now we can make sure all apps are running by going to 8761. You can see we have the API gateway in the car service. Then if we were to log in with localhost 8080, it'll take us to OZ0. We can use our credentials here. If you don't have credentials, you can click the sign up or log in with Google. That'll work just fine. Now it's returning my name. If we looked in the API gateway, that comes from the home controller. Set up this decay here. You'll see it's just printing out my full name from the OIDC user object. If we go to slash home, it actually prints it out from the car service. This is the car service right here. It prints out all the claims that are in the JWT. If we look for the other home controller in the car service, you'll see what that looks like. What's happening is in the application.yaml for the API gateway, it is proxying with Spring Cloud Gateway and using a token relay filter to pass the access token down to the car service. This is how we're mapping that home down to it. Also in the API gateway, we have a cool car controller which uses web client and circuit breaker and talks down to that car service to grab that list of cars and filter out the ones that aren't cool. If we go back here and just do cool cars, you can see that it's filtered out the ones that aren't so cool. The other feature is we could get an access token with print token here. I'll print that to our console and then we can grab it. We could set that in a terminal as token equals. Then we'll use HTTPIE to talk to the car service without filtering out any cars. Let's do authorization, bear a token, and you'll see it's got the ones that aren't so cool in there. It proves that access token works within the microservices architecture as well as outside of it. One of the cool things that's automatically supported by Spring Security is refresh tokens. To get a refresh token, you have to pass in an offline access scope. Let's modify the API gateway, ENV file, to use a different audience, one that expires the access token every 30 seconds. By default, I think it's an hour or something like that. I don't want to wait an hour. We're going to create a new audience or a new API in AusZero that expires a lot quicker. To make that new property scopes work, we have to modify the application.properties in the API gateway. These are actually read using spring.env, that's already configured in the project. That's why you have one in your .env, you need it in your properties file as well. Here we are. Then we added some debugging to show the access token getting refreshed. We need to create an API on AusZero using AusZero APIs create. The name is fast expiring the identifier as this HTTPS fast expiring API in the token lifetime is 30 seconds. We'll go ahead and create that. Then we can restart the API gateway. Pull this into its own window here. Put that on the right. Then if we were to log in an incognito window, you'll see when it prompts us for consent, it also has that allow offline access. That's how you know you're getting a refresh token too. Once that happens, it prints the access token to the console. You can see this expires that value here. We'll use this timestamp converter to put it in our own time. Currently 30242 expires at 30257. We'll wait for that to expire. Now if we refresh, we should get a new access token. If we look back at our console, you'll see sure enough, this was the last one that expired at 257. HTTPS posts to the token to get a new one. This one's at 334. We're getting a new refresh token. Spring Security handles that all for us. As long as it has that refresh token in the beginning, it goes and gets a new access token. It's the most secure way of doing things because you want your access token to expire quickly because you can't revoke them. You can revoke refresh tokens. If you want to learn more, there is a demo script in this same project. It's written in ASCII Doctor. If you have the ASCII Doctor plugin, you can see a nice pretty view here. It basically builds everything step by step. It shows you how to do it from the very get go and creating all the projects using start.spring.io. Also, we have a microservices lab. If you're looking for something a little more formal, this steps through very similar to the demo script. I created the demo script first and then created the lab from that. It just steps you through everything with nice, concise steps. It looks a little prettier. You don't need the ASCII Doctor plugin to make it outward. Thanks for watching. I hope you learned a fair bit. If you want to create it all yourself, go check out the blog post. Try the demo script. Try the lab. If you like this screencast, I post a lot of them or I try to. I post frequent tutorials on Twitter. You can find me at MRABLE. I'm also on LinkedIn at MRABLE and on GitHub at MRABLE. You can find my whole team at Octadev on Twitter and subscribe to our YouTube channel because we have a lot of good content about identity and full stack applications and microservices. Enjoy. Have a great day.