# Baeldung's spring-security-oauth: runnable modules for Spring Security 5 OAuth examples

> This repository holds the companion code for Baeldung's Spring Security OAuth articles, organised as a Maven multi-module project with Spring Boot applications and Angular front ends. It is not a library to install as a dependency, and its hardcoded test credentials exist for local exploration only.

**Baeldung/spring-security-oauth** — Getting Started withg Spring Security OAuth: 

- Repository: https://github.com/Baeldung/spring-security-oauth
- Website: http://bit.ly/github-lsso
- Stars: 2,027 · Forks: 1,904
- Language: Java
- License: MIT
- Published: 2026-10-11 · Updated: 2026-10-11 · Language: en
- Canonical page: https://hysenlabs.com/projects/baeldung-spring-security-oauth

## A code companion for Baeldung tutorials, not a distributable library

Baeldung/spring-security-oauth is the repository behind Baeldung's Spring Security OAuth course, linked from the README at http://bit.ly/github-lsso. Nothing in the repository publishes a library to Maven Central, and no dependency coordinates are documented. Engineers who arrive expecting an SDK or a starter library will find a collection of runnable Spring Boot applications instead.

Cloning and building locally is the entire documented use case. Each module is a self-contained instructional unit covering a specific aspect of OAuth2 in Spring, and the project treats them as separate examples rather than a unified framework. Understanding that boundary up front saves time: this repository teaches OAuth2 patterns but does not implement them in a way you can import.

Top-level repository entries include oauth-authorization-server-with-redis/, oauth-authorization-server/, oauth-resource-server/, and oauth-sso/ alongside the four modules the README describes. Those additional directories have no README description, so their purpose has to be inferred from the directory names alone.

## Four modules, two eras: legacy OAuth2 versus Spring Security 5

Baeldung organised the examples into four named modules. oauth-rest illustrates the Spring Security 5 approach end to end: Keycloak acts as the Authorization Server, a Resource Server exposes protected endpoints, and an Angular application handles the client side. oauth-jwt repeats that pairing but directs attention to JWT, covering how tokens are issued and validated under the same Spring Security 5 stack.

oauth-jws-jwk-legacy targets a narrower scenario: integrating JSON Web Signatures and JSON Web Key Sets within an application on the older Spring Security OAuth2 library, which predates the current Spring Security 5 approach. oauth-legacy collects a broader set of older examples, including Authorization Server, Resource Server, Angular and AngularJS clients, all written against the legacy library.

Engineers starting a new project should look at the Spring Security 5 modules rather than the legacy ones, because Spring replaced the older library with its own OAuth2 support in Spring Security 5. Patterns from oauth-legacy do not transfer directly to oauth-rest, and mixing configuration from the two eras produces errors that require understanding both stacks to diagnose.

Keycloak is a prerequisite for the Spring Security 5 modules. Without a running instance, oauth-rest and oauth-jwt cannot complete the authorization flow, and the README does not include Keycloak setup steps.

## Building the project and running a module from the command line

Building the entire project runs from the repository root:

```bash
mvn clean install
```

Starting any sub-module afterwards uses the Spring Boot Maven plugin:

```bash
mvn spring-boot:run
```

Spring STS is also supported: modules can be imported and run from the Boot Dashboard, as the README notes. After starting the Password Grant module, it is reachable at http://localhost:8084/. Login there uses the credentials the README gives: username john and password 123.

Those credentials reflect a tutorial setup and carry no security implication in a local context. Anybody who runs these modules outside a developer machine would need to replace them, and the README gives no guidance on how to configure alternative credentials in each module.

At the repository root, pom.xml defines the multi-module layout, Jenkinsfile contains the CI configuration, and CONTRIBUTING.md documents contribution guidelines. LICENSE holds the MIT text.

## Angular 7 front ends need npm locally, and Jenkins skips them

Three Angular 7 front-end modules accompany the project: spring-security-oauth-ui-implicit-angular, spring-security-oauth-ui-password-angular, and oauth-ui-authorization-code-angular. Running any of them requires additional steps beyond mvn clean install.

After the Maven build, change into the Angular application directory:

```bash
cd src/main/resources
```

Install JavaScript dependencies:

```bash
npm install
```

Start the application:

```bash
npm start
```

Angular 7 modules are commented out in the Jenkinsfile because the Jenkins environment does not have npm. They build locally but receive no automated build verification, which is worth knowing if you plan to fork the project and extend the CI pipeline.

For Angular versions below 4.3.0, HttpClient and HttpClientModule imports in app.module and app.service.ts must be commented out, since those older versions rely on HttpModule. Angular 7 itself is no longer under active maintenance by the Angular team, meaning the front-end code in this repository targets a framework version that will not receive further security updates from its authors.

## The PKCE SPA client exposes each step of the authorization_code flow

clients-SPA-legacy/clients-js-only-react-legacy is a Spring Boot application serving two React single-page applications. Its stated purpose is to demonstrate the authorization_code flow with PKCE on a JavaScript-only client, covering both a guided walkthrough and a realistic login scenario.

Once the Spring Boot application is running, the Step-By-Step page is at http://localhost:8080/pkce-stepbystep/index.html. It walks through each step required to obtain an access token, and notes that a user account may need to be created before the login form accepts credentials. Swapping in a different Authorization Server is supported by adding or uncommenting entries in static/spa/js/configs.js.

Reaching all features of the Real Case page at http://localhost:8080/pkce-realcase/index.html requires starting the resource server at clients-SPA-legacy/oauth-resource-server-auth0-legacy separately. A deliberate limitation is built into that page: removing resources fails because the application was configured without the permissions the resource server demands for that operation. That behaviour exists to illustrate what happens when the scope requested at login does not cover a protected action.

A third page within the Real Case application contains exactly the code shown in the related Baeldung article, so readers can compare the running behaviour with the printed code side by side.

## No GitHub releases, no tagged version, and a last push of 2026-06-26

No GitHub releases have been published. There is no tagged version to reference, no changelog entry to read and no artifact with a fixed identifier. Building from the repository means building from whatever commit is current on the master branch, with no documented way to identify a known-good state.

Absence of releases is consistent with an educational project. Tutorial code does not need semantic versioning. What it does mean in practice is that two engineers cloning the repository at different times may encounter different code, and a bug report without a specific commit hash is difficult to reproduce reliably.

Last push was on 2026-06-26, and the repository is not archived. MIT is the declared license, and the LICENSE file at the repository root holds the authoritative text. Repository topics list oauth, spring-security, and spring-security-oauth, which places it firmly within the Spring ecosystem rather than as a general OAuth2 reference.

## When tutorial code becomes a liability: gaps in security and configuration

Adopting this repository as a base for production work creates problems the examples were not designed to avoid. Hardcoded credentials (username john, password 123) appear in the Password Grant module and are documented in the README as expected for local tutorial use. Replacing them across all modules is the first step any real deployment would require, and the repository does not describe how to do that or where to look in each module's configuration.

Keycloak's configuration is assumed rather than documented. Both oauth-rest and oauth-jwt use Keycloak as the Authorization Server, but the README gives no steps for setting up client IDs, scopes, redirect URIs or Keycloak-specific configuration properties. An engineer who wants to adapt either module for a different identity provider has to locate and reverse-engineer the relevant configuration from the application properties files scattered across the module directories.

Legacy and current patterns coexist in the repository without a clear marker. oauth-legacy uses the older Spring Security OAuth2 API, which has been superseded. Nothing in the code itself labels which modules implement deprecated patterns and which reflect current best practice, so an engineer who picks the wrong module as a starting point may invest time into an approach Spring no longer recommends.

## Conclusion

Use this repository if you are following Baeldung's Spring Security OAuth articles and want to run the example code locally alongside the tutorials. Skip it if you need a published Maven artifact, a production-ready configuration or a security review of the OAuth setup, because the repository provides none of those. Before you build, confirm you have a local Keycloak instance for the oauth-rest and oauth-jwt modules, and check whether the Angular 7 front ends match the Node.js version on your machine, since those modules are excluded from the Jenkins build.

## FAQ

### What is Baeldung/spring-security-oauth?

It is a Maven multi-module project containing runnable Spring Boot and Angular applications that accompany Baeldung's tutorials on Spring Security OAuth. It is not a library to install as a Maven dependency, and it publishes no artifact to Maven Central.

### How do I build and run the spring-security-oauth modules?

Run mvn clean install from the repository root to build the project, then run mvn spring-boot:run inside a sub-module directory to start it. The Password Grant module is accessible at http://localhost:8084/ with username john and password 123.

### What is the difference between oauth-legacy and oauth-rest?

oauth-legacy covers the older Spring Security OAuth2 library, which has been superseded. oauth-rest is built on Spring Security 5 and uses Keycloak as the Authorization Server. New projects should use the Spring Security 5 modules.

### Does Baeldung/spring-security-oauth support PKCE?

The clients-SPA-legacy/clients-js-only-react-legacy module demonstrates the authorization_code flow with PKCE for JavaScript-only SPAs, with a Step-By-Step page at http://localhost:8080/pkce-stepbystep/index.html.

### Can I use Baeldung/spring-security-oauth in a production application?

It is designed for local tutorial exploration and contains hardcoded credentials, no deployment documentation and no GitHub releases. Its Angular modules are excluded from the Jenkins CI build, and Keycloak setup is not documented.

## Sources

- [Baeldung/spring-security-oauth on GitHub](https://github.com/Baeldung/spring-security-oauth)
- [Issues](https://github.com/Baeldung/spring-security-oauth/issues)
- [License: MIT](https://github.com/Baeldung/spring-security-oauth/blob/master/LICENSE)
- [Project website](http://bit.ly/github-lsso)
- [README](https://github.com/Baeldung/spring-security-oauth/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/baeldung-spring-security-oauth