The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Short answer: an authorization server issues access tokens after authenticating and authorizing a client. For a new application, use Spring Authorization Server through Spring Boot’s spring-boot-starter-oauth2-authorization-server. A Spring Boot 2 application is a different, historical case: Boot 2.0 stopped managing the older Spring Security OAuth server project, so retaining that design requires the separate spring-security-oauth2-autoconfigure bridge and matching legacy documentation.
Do not copy an @EnableAuthorizationServer example into a current Spring Security project. First identify which generation your application uses, then follow the corresponding setup below.
Choose the setup that matches your application
| Situation | Use | Important qualification |
|---|---|---|
| New development or an upgrade to the current Spring stack | Spring Authorization Server with Spring Boot’s spring-boot-starter-oauth2-authorization-server |
The current getting-started documentation requires Java 17 or later: Spring Security Authorization Server Getting Started. |
| Existing Boot 2 application that must keep the older OAuth server implementation | The explicitly added spring-security-oauth2-autoconfigure bridge and the versioned OAuth2 Boot documentation |
This is a maintenance path. Boot 2 minor-version compatibility must be checked against the project’s exact Spring Security and OAuth2 Boot versions. |
| OAuth client or resource server only | Spring Security OAuth2 client or resource-server configuration | Neither role is an authorization server. Spring Boot documents them as separate dependency and configuration paths: Spring Boot OAuth2 reference. |
Spring’s feature matrix records that Boot 2.0 dropped support for the older Spring Security OAuth project’s managed features, while Boot 2 continued to support OAuth 2.0 clients and resource servers through Spring Security. The bridge was provided to ease migration: OAuth 2.0 Features Matrix.
What an authorization server must do
The server authenticates a user, obtains the user’s authorization where required, and issues tokens to a registered client. A client is an application requesting a token; a resource server is the API that validates the token. A single deployment can contain more than one role, but each role has its own configuration.
#1 Best Overall
- Lifetime warranty!
- Small enough to fit on a key ring
- Universal compatibility with HID proximity card readers
- Provides an external number for easy identification and control Can be placed on a key ring for conv
- Supports formats up to 85 bits, with over 137 billion codes
At minimum, configure a client registration, the server’s issuer, signing keys, and the security rules that protect the endpoints. Depending on enabled features, the server exposes authorization, token, introspection, revocation, metadata, and JWK Set endpoints. The JWK Set endpoint is configured only when a JWKSource bean is available. See the Authorization Server configuration model.
Current setup with Spring Authorization Server
1. Start with the supported runtime and starter
Use Java 17 or newer and let your selected Spring Boot release manage compatible Spring Security versions. Add the Boot starter rather than assembling the authorization-server modules manually:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-oauth2-authorization-server</artifactId>
</dependency>The starter belongs to the current Spring Authorization Server generation, not to a Boot 2 application using the old OAuth project. The official getting-started page shows the complete dependency and application arrangement for the current line.
Rank #2
- POWERFUL SECURITY KEY: The Security Key C NFC is the essential physical passkey for protecting your digital life from phishing attacks. It ensures only you can access your accounts.
- WORKS WITH 1000+ ACCOUNTS: Compatible with Google, Microsoft, and Apple. A single Security Key C NFC secures 100 of your favorite accounts, including email, password managers, and more.
- FAST & CONVENIENT LOGIN: Plug in your Security Key C NFC via USB-C and tap it, or tap it against your phone (NFC) to authenticate. No batteries, no internet connection, and no extra fees required.
- TRUSTED PASSKEY TECHNOLOGY: Uses the latest passkey standards (FIDO2/WebAuthn & FIDO U2F) but does not support One-Time Passwords. For complex needs, check out the YubiKey 5 Series.
- BUILT TO LAST: Made from tough, waterproof, and crush-resistant materials. Manufactured in Sweden and programmed in the USA with the highest security standards.
2. Register one local client
Spring Boot can create initial authorization-server beans from client-registration properties. The following is a local-development pattern based on the current reference; replace the sample values and keep them out of production source control.
Free tools Windows power users keep installed
One-click scans. No signup required.
server:
port: 9000
spring:
security:
user:
name: user
password: change-me
oauth2:
authorizationserver:
client:
demo:
registration:
client-id: demo-client
client-secret: demo-secret
client-authentication-methods:
- client_secret_basic
authorization-grant-types:
- authorization_code
- refresh_token
redirect-uris:
- http://127.0.0.1:8080/login/oauth2/code/demo
scopes:
- openid
- profile
require-authorization-consent: trueThis registration gives the client an identifier and secret, declares how it authenticates, limits the grants it may use, and allowlists the redirect URI and scopes. A redirect URI must be an exact, pre-registered destination; do not use a wildcard to make local testing convenient. The openid scope requests OpenID Connect behavior, while other scopes should represent only the API permissions the client actually needs.
3. Add application security deliberately
Use a SecurityFilterChain to decide which application requests are public, require authentication for the authorization flow, and enable a login mechanism such as form login. The current model also supports enabling OpenID Connect 1.0 through the authorization-server configuration. Keep the authorization-server chain and any application or resource-server chain ordered and separated according to the current Spring Security reference rather than combining unrelated examples.
Rank #3
- Note: These are 125kHz key fobs (tags). If you want to add them to your lock system, please ensure that your system uses the same frequency of unencrypted 125kHz. Not compatible with other frequencies like 13.56MHz. For example, they don't work for Tuya or TTLock smart locks. Not work for encrypted systems.
- Compatible with other universal 125kHz tags like EM4100/4102. Not compatible with encrypted tags like HID, Indala, Cobra, APCiK, Paradox, Kaba, Isonas, etc.
- Read only. Not rewritable. You cannot re-program them. Each key fob is already pre-programmed with a unique ID number. The 10-digit number is engraved on the tag casing.
- Suitable for 125kHz RFID proximity access control system and ID management system. For example, add it to your RFID door lock if applicable.
- Approx. Size: 1.4*1.1*0.2 inch. Casing Material: ABS Plastic. Package includes 100 PCS.
4. Set issuer, keys, and endpoints
The issuer is the stable identifier clients use to validate metadata and tokens. Endpoint paths cover authorization, token exchange, introspection, revocation, provider metadata, and JWK publication. Signing keys are not a client property: the server uses a JWKSource to sign tokens, and publishes the corresponding public keys through the JWK Set endpoint when that bean exists. Override AuthorizationServerSettings, JWKSource, JwtDecoder, or a security filter chain when the defaults do not match your deployment.
For a local demonstration, generated or in-memory keys can be acceptable. For a real deployment, use a managed key lifecycle, stable issuer URL, protected private keys, and a rotation plan. Clients and resource servers must be able to reach the issuer and public-key metadata they are configured to trust.
5. Replace in-memory client storage before production
Boot’s auto-configuration uses InMemoryRegisteredClientRepository. The reference describes that repository as limited and suitable for development. Production deployments should use JdbcRegisteredClientRepository or a custom RegisteredClientRepository backed by durable storage. Persist client identifiers, hashed or otherwise protected secrets where appropriate, redirect URIs, grant types, scopes, and consent-related settings under your organization’s security and retention policies.
Rank #4
- Standard 125Khz ID RFID keyfob, support 125khz proximity ID cards token tag duplication. Frequency : 125kHz; Sensing Distance: 2.5 to 10 cm (1 to 4 inch); Data Storage Life: 10 Years
- Note: These are blank key tags without pre-programmed card numbers. You cannot directly add them to RFID locks or use a card reader to read them. Before using, please write data(card numbers) into them by a 125kHz RFID card writer first.
- Product Size: 40*30*4mm(1.57*1.18*0.16 inch). High-Quality Copper Coil inside. Casing Material: ABS Plastic. Waterproof and heat-resistant.
- Chip: ATMEL T5577 (compatible with other universal 125kHz tags). Frequency: 125kHz; It's rewritable, and it can write in 125khz id format and H-ID WG 125khz format, can be customised to 26-bit Prox format. Compatible with T5567 T5577 EM4305.
- Applications: Hotel key chain, Access control systems, time attendance system, ticketing, packing card. This T5577 proximity key card can copy duplicate em4100 TK4100 ID Card Keychains tags.
Maintaining a Boot 2 authorization server
Why the old examples no longer apply automatically
Boot 2.0 removed managed support for the older Spring Security OAuth project’s authorization-server features. The compatibility route was to add spring-security-oauth2-autoconfigure explicitly. The OAuth2 Boot 2.3.12 reference describes that project as a bridge for Boot 2.x and marks the older OAuth projects as maintenance mode: Spring Security OAuth2 Boot 2.3.12 reference.
What the historical recipe contains
The versioned OAuth2 Boot 2.2.7 authorization-server page uses the legacy dependency arrangement, @EnableAuthorizationServer, and at least one client ID and secret: OAuth2 Boot 2.2.7 Authorization Server. That annotation belongs to the old implementation. It should not be combined with the current Spring Authorization Server starter, current endpoint beans, or current configuration examples.
Because Spring Boot 2 has several minor releases and the exact target version is not established here, there is no single responsible copy-and-paste dependency block for every Boot 2 project. Pin the bridge, Spring Security, and Boot versions to the application’s existing dependency-management line, then use the matching versioned reference. Check transitive dependencies and run the project’s integration tests before changing authentication behavior.
Best Value
- POWERFUL SECURITY KEY: The YubiKey 5 NFC is the most versatile physical passkey, protecting your digital life from phishing attacks. It ensures only you can access your accounts
- WORKS WITH 1000+ ACCOUNTS: Compatible with popular accounts like Google, Microsoft, and Apple. A single YubiKey 5 NFC secures 100+ of your favorite accounts, including email, password managers, and more
- FAST & CONVENIENT LOGIN: Plug in your YubiKey 5 NFC via USB and tap it, or tap it against your phone (NFC), to authenticate. No batteries, no internet connection, and no extra fees required
- MOST SECURE PASSKEY: Supports FIDO2/WebAuthn, FIDO U2F, Yubico OTP, OATH-TOTP/HOTP, Smart card (PIV), and OpenPGP. That means it’s versatile, working almost anywhere you need it
- PRIMARY & SPARE KEYS: Just like having a spare house key, we recommend buying two YubiKeys - one for daily use and one as a spare. That way you’ll never get locked out of your accounts
When to stop extending the legacy path
If you control the application’s upgrade schedule, plan a migration to the current Spring Authorization Server model instead of adding new features to the maintenance bridge. Migration normally requires revisiting client registrations, token claims, signing keys, issuer metadata, endpoint URLs, consent behavior, and persistence. Test existing clients and APIs against the new issuer and key set before switching traffic.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Configuration decisions that affect clients
| Decision | Effect | Safer default for a demonstration |
|---|---|---|
| Client authentication method | Determines how the client proves its identity at the token endpoint. | Use a confidential client method such as client_secret_basic only for a client capable of protecting a secret. |
| Grant types | Limits which OAuth flows the client may request. | Enable only the grants required by the client; authorization code plus refresh token is a common current example. |
| Redirect URI | Controls where an authorization response may be delivered. | Register one exact localhost URI for testing; use HTTPS and exact production URIs outside local development. |
| Scopes | Defines the permissions and, with openid, whether OpenID Connect identity information is requested. |
Start with the smallest set the application needs. |
| Consent | Controls whether the user is shown a consent screen before authorization. | Require consent while testing the user experience; make any production policy explicit. |
Common failure modes
- Missing authorization-server classes: the project is probably using Boot 2 without the legacy bridge, or a current project without the current starter. Check the intended generation before changing imports.
- Redirect URI mismatch: compare scheme, host, port, path, and trailing characters with the registered value. The authorization request and registration must match exactly.
- Invalid client: verify the client ID, secret, and token-endpoint authentication method. A public client cannot safely use a secret-based method.
- Issuer or discovery errors: confirm that the configured issuer is stable and reachable from the client and that metadata endpoints advertise the same issuer.
- JWK or signature validation failure: ensure a
JWKSourceexists, the JWK Set endpoint is reachable, and the resource server trusts the issuer’s published keys. - Clients disappear after restart: an in-memory registered-client repository was used. Replace it with JDBC or a custom persistent repository for shared or production environments.
- Boot starts but requests are denied: inspect the active
SecurityFilterChainrules and login configuration; authorization-server endpoint protection does not automatically make unrelated application routes public.
How the Spring project has changed
Spring announced on September 11, 2025 that Spring Authorization Server would move into Spring Security 7.0, consolidating its documentation and source there: Spring Authorization Server moving to Spring Security 7.0. That project lineage change reinforces the practical rule for this topic: treat Boot 2 OAuth2 Boot examples and current Spring Security Authorization Server examples as separate generations, not interchangeable snippets.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
