SivaLabs

jOOQ is a Java persistence library that provides SQL DSL for writing typesafe SQL queries. It supports most of the popular databases like MySQL, PostgreSQL, Oracle, SQL Server, and many more. In this tutorial, we will learn how to get started with jOOQ for implementing persistence layer in a Spring Boot application. You can also use jOOQ in other JVM based languages like Kotlin, Scala, etc. jOOQ Tutorial - 1 : Getting Started jOOQ Tutorial - 2 : Implementing CRUD Operations jOOQ Tutorial - 3 : Fetching One-to-One Relationships jOOQ Tutorial - 4 : Fetching One-to-Many Relationships jOOQ Tutorial - 5 : Fetching Many-to-Many Relationships In this jOOQ tutorial series, you will learn how to use jOOQ in a Spring Boot application for implementing:

In this article, we will learn how to implement Service to Service Communication using Client Credentials Flow. We will create the archival-service in which we will use a scheduler job to invoke the messages-service APIs to archive the messages. For implementing this, we will use Client Credentials Flow. We will also implement POST /api/messages/archive API endpoint in archival-service which can only be called by users who have ROLE_ADMIN role. Considering this, archival-service will act as a Resource Server and as a Client too.

In the previous articles, we have created messages-webapp and messages-service and invoked API endpoints using Postman. In this article, we will learn how to invoke the secured messages-service API endpoints from the Client application messages-webapp. Source Code: You can find the complete source code of this project on GitHub: https://github.com/sivaprasadreddy/spring-security-oauth2-microservices-demo Show List of Messages As GET /api/messages API endpoint in messages-service is publicly accessible, we can invoke it from messages-webapp without any authentication.

In the previous article, we have created messages-webapp and secured it with Spring Security OAuth 2.0 using Authorization Code Flow. In this article, we will create messages-service, which is a Spring Boot Resource Server, and secure it with Spring Security OAuth 2.0. Source Code: You can find the complete source code of this project on GitHub: https://github.com/sivaprasadreddy/spring-security-oauth2-microservices-demo Create messages-service You can generate messages-service using Spring Initializr by clicking on this link.

In this article, we will create messages-webapp which is a Spring MVC + Thymeleaf web application and secure it with Spring Security OAuth 2.0 using Keycloak. Source Code: You can find the complete source code of this project on GitHub: https://github.com/sivaprasadreddy/spring-security-oauth2-microservices-demo Setup Keycloak using Docker Compose In the previous article, we have already seen how to setup Keycloak using Docker Compose. Create docker-compose.yml file with the following content: version: '3.8' name: spring-security-oauth2-microservices-demo services: keycloak: image: quay.

In the previous articles, we have learned about various OAuth 2.0 / OpenID Connect flows using web browser, cURL and Postman. Now it’s time to put what we have learned into practice. What better way to do that than to build a sample project? While implementing OAuth 2.0 / OpenID Connect based security using a Security framework like Spring Security, many activities are performed by the framework under the hood. It is important to understand what is happening under the hood so that we can use the framework effectively.

In the Part 4: OAuth 2.0 Authorization Code Flow with PKCE, we learned how to acquire access_token using Authorization Code Flow with PKCE. In this article, we will explore how to use Implicit Flow and Resource Owner Password Credentials Flow. IMPORTANT The Implicit Flow and Resource Owner Password Credentials Flow are DEPRECATED. Unless you have a good reason, you shouldn’t be using them. Implicit Flow The Implicit Flow is a kind of shorter version of Authorization Code Flow where you will be directly getting access_token using authorization_endpoint itself.

In the Part 3: OAuth 2.0 Client Credentials Flow, we learned how to acquire access_token using Client Credentials Flow. In this article, we will explore how to use Authorization Code Flow with PKCE. Authorization Code Flow with PKCE The Authorization Code Flow with PKCE is an OpenId Connect flow primarily designed to secure native, mobile applications and Single Page Applications (SPA). The PKCE, typically pronounced as “pixy”, is an acronym for Proof Key for Code Exchange.

In the Part 2: OAuth 2.0 Authorization Code Flow, we learned how to authenticate a user using Authorization Code Flow. In this article, we will explore how to use Client Credentials Flow that is typically used for Service-to-Service communication without any user (Resource Owner) context. Client Credentials Flow Sometimes a Resource Server needs to interact with another Resource Server without any user context. For instance, Resource Server A may run a scheduled job that will invoke a secured REST API endpoint on Resource Server B.

In the Part 1: Getting familiar with OAuth 2 concepts, we learned how to set up Keycloak, created a realm, a client with Standard flow enabled and a user. In this Part 2, you will learn how to authenticate a user using Authorization Code Flow. First of all, let’s clear up the confusion between Authorization Code Grant Type vs Authorization Code Flow. As I mentioned earlier, OAuth 2.0 spec concern about only Authorization and OpenID Connect spec is added as a layer on top of OAuth 2.