This is an authorization server implementation in Java which supports OAuth 2.0 and OpenID Connect.
This implementation is written using the Jakarta RESTful Web Services API (Jakarta REST, formerly known as JAX-RS) and the authlete-java-jakarta library. Jakarta REST is part of Jakarta EE. This server targets the Jakarta EE 10 stack (Jakarta REST 3.1 / Servlet 6.0, Jersey 3.1) and builds and runs on Java 25. On the other hand, authlete-java-jakarta library is an open source library which provides utility classes for developers to implement an authorization server and a resource server. authlete-java-jakarta in turn uses authlete-java-common library which is another open source library to communicate with Authlete Web APIs.
Note: This server was previously built on the legacy Java EE stack (JAX-RS 2.0 /
javax.*, Jersey 2, Servlet 3, Java 8). It has been migrated to Jakarta EE 10 (jakarta.*), so it now deploys cleanly to modern servlet containers such as Tomcat 10+ and Jetty 12. The default Authlete API version is also now Authlete 3.0 (see Configuration File).
This implementation is DB-less. What this means is that you don't have to have a database server that stores authorization data (e.g. access tokens), settings of the authorization server itself and settings of client applications. This is achieved by using Authlete as a backend service.
Access tokens issued by this authorization server can be used at a resource server which uses Authlete as a backend service. java-resource-server is such a resource server implementation. It includes an example implementation of protected resource endpoint.
Apache License, Version 2.0
JSON files under src/main/resources/ekyc-ida have been copied from
https://bitbucket.org/openid/ekyc-ida/src/master/examples/response/ .
Regarding their license, ask the eKYC-IDA WG of OpenID Foundation.
https://github.com/authlete/java-oauth-server
Authlete is a cloud service that provides an implementation of OAuth 2.0 & OpenID Connect (overview). You can easily get the functionalities of OAuth 2.0 and OpenID Connect either by using the default implementation provided by Authlete or by implementing your own authorization server using Authlete Web APIs as this implementation (java-oauth-server) does.
To use this authorization server implementation, you need to get API credentials
from Authlete and set them in authlete.properties. The steps to get API
credentials are very easy. All you have to do is just to register your account
(sign up). See Getting Started for details.
-
Download the source code of this authorization server implementation.
$ git clone https://github.com/authlete/java-oauth-server.git $ cd java-oauth-server -
Edit the configuration file to set the API credentials of yours.
$ vi authlete.properties -
Make sure that you have installed maven and a JDK 25 (or later) and set
JAVA_HOMEproperly. -
Start the authorization server on http://localhost:8080.
$ mvn jetty:run &
If you would prefer to use Docker, just hit the following command after the step 2.
$ docker-compose up
java-oauth-server refers to authlete.properties as a configuration file.
If you want to use another different file, specify the name of the file by
the system property authlete.configuration.file like the following.
$ mvn -Dauthlete.configuration.file=local.authlete.properties jetty:run &
By default, authlete.properties is configured for Authlete 3.0 (API V3):
set your service's cluster base_url (e.g. https://jp.authlete.com), the
service.api_key and a service.access_token. If you still use Authlete 2.x,
the file contains a commented "Authlete 2.x (legacy)" block you can switch to
(API key + API secret on https://api.authlete.com).
This implementation exposes endpoints as listed in the table below.
| Endpoint | Path |
|---|---|
| Authorization Endpoint | /api/authorization |
| Token Endpoint | /api/token |
| JWK Set Endpoint | /api/jwks |
| Discovery Endpoint | /.well-known/openid-configuration |
| Revocation Endpoint | /api/revocation |
| Introspection Endpoint | /api/introspection |
| UserInfo Endpoint | /api/userinfo |
| Dynamic Client Registration Endpoint | /api/register |
| Pushed Authorization Request Endpoint | /api/par |
| Grant Management Endpoint | /api/gm/{grantId} |
| Federation Configuration Endpoint | /.well-known/openid-federation |
| Federation Registration Endpoint | /api/federation/register |
| Credential Issuer Metadata Endpoint | /.well-known/openid-credential-issuer |
| JWT Issuer Metadata Endpoint | /.well-known/jwt-issuer |
The authorization endpoint and the token endpoint accept parameters described in RFC 6749, OpenID Connect Core 1.0, OAuth 2.0 Multiple Response Type Encoding Practices, RFC 7636 (PKCE) and other specifications.
The JWK Set endpoint exposes a JSON Web Key Set document (JWK Set) so that client applications can (1) verify signatures by this OpenID Provider and (2) encrypt their requests to this OpenID Provider.
The configuration endpoint exposes the configuration information of this OpenID Provider in the JSON format defined in OpenID Connect Discovery 1.0.
The revocation endpoint is a Web API to revoke access tokens and refresh tokens. Its behavior is defined in RFC 7009.
The introspection endpoint is a Web API to get information about access tokens and refresh tokens. Its behavior is defined in RFC 7662.
The userinfo endpoint is a Web API to get information about an end-user. Its behavior is defined in Section 5.3. UserInfo Endpoint of OpenID Connect Core 1.0.
The dynamic client registration endpoint is a Web API to register and update client applications. Its behavior is defined in RFC 7591 and RFC 7592.
The pushed authorization request endpoint (a.k.a. PAR endpoint) is a Web API to register an authorization request in advance and obtain a request URI. Its behavior is defined in RFC 9126.
The grant management endpoint is a Web API to get information about a grant ID and revoke a grant ID. Its behavior is defined in Grant Management for OAuth 2.0.
The federation configuration endpoint is a Web API that publishes the entity configuration of the authorization server in the JWT format. Its behavior is defined in OpenID Federation 1.0.
The following is an example to get an access token from the authorization
endpoint using Implicit Flow. Don't forget to replace {client-id} in
the URL with the real client ID of one of your client applications. As for
client applications, see Getting Started and the document of
Developer Console.
http://localhost:8080/api/authorization?client_id={client-id}&response_type=token
The request above will show you an authorization page. The page asks you to input login credentials and click "Authorize" button or "Deny" button. Use one of the following as login credentials.
| Login ID | Password |
|---|---|
| john | john |
| jane | jane |
| max | max |
| inga | inga |
Of course, these login credentials are dummy data, so you need to replace the user database implementation with your own.
The account max is for the old draft of
OpenID Connect for Identity Assurance 1.0 (IDA). The account holds
verified claims in the old format. Authlete 2.2 accepts the old format
but Authlete 2.3 onwards will reject it.
The account inga is for the third Implementer's Draft of IDA onwards.
Use inga for testing the latest IDA specification. However, note that
the third Implementer's Draft onwards is supported from Authlete 2.3.
Older Authlete versions do not support the latest IDA specification.
How to customize this implementation is described in CUSTOMIZATION.md. Basically, you need to do programming for end-user authentication because Authlete does not manage end-user accounts. This is by design. The architecture of Authlete carefully separates authorization from authentication so that you can add OAuth 2.0 and OpenID Connect functionalities seamlessly into even an existing web service which may already have a mechanism for end-user authentication.
This implementation uses Viewable class to implement the authorization page.
The class is included in Jersey (the reference implementation of Jakarta
REST), but it is not a part of the Jakarta REST API.
- RFC 6749 - The OAuth 2.0 Authorization Framework
- RFC 6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage
- RFC 6819 - OAuth 2.0 Threat Model and Security Considerations
- RFC 7009 - OAuth 2.0 Token Revocation
- RFC 7033 - WebFinger
- RFC 7515 - JSON Web Signature (JWS)
- RFC 7516 - JSON Web Encryption (JWE)
- RFC 7517 - JSON Web Key (JWK)
- RFC 7518 - JSON Web Algorithms (JWA)
- RFC 7519 - JSON Web Token (JWT)
- RFC 7521 - Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants
- RFC 7522 - Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants
- RFC 7523 - JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants
- RFC 7591 - OAuth 2.0 Dynamic Client Registration Protocol
- RFC 7592 - OAuth 2.0 Dynamic Client Registration Management Protocol
- RFC 7636 - Proof Key for Code Exchange by OAuth Public Clients
- RFC 7662 - OAuth 2.0 Token Introspection
- RFC 9126 - OAuth 2.0 Pushed Authorization Requests
- OAuth 2.0 Multiple Response Type Encoding Practices
- OAuth 2.0 Form Post Response Mode
- OpenID Connect Core 1.0
- OpenID Connect Discovery 1.0
- OpenID Connect Dynamic Client Registration 1.0
- OpenID Connect Session Management 1.0
- Authlete - Authlete Home Page
- authlete-java-common - Authlete Common Library for Java
- authlete-java-jakarta - Authlete Library for Jakarta (Java)
- java-resource-server - Resource Server Implementation
| Purpose | Email Address |
|---|---|
| General | info@authlete.com |
| Sales | sales@authlete.com |
| PR | pr@authlete.com |
| Technical | support@authlete.com |