WARNING - NOT PRODUCTION READY
The motivation behind this project was to explore an opinionated OAuth 2.1 & OIDC implementation. The aim is to create an implementation that is useful for developers to both understand the concepts of OAuth 2.1 and OIDC, as well as, provide a useful environment to explore the OAuth/OIDC concepts.ter
The Domain Model is an attempt to build a ubiquitous language for discussing the major concepts of the Application.
The AuthorizationServer is the containing concept for the rest of the domain. All other models live within a particular AuthorizationServer.
An Application is an actor that can initiate a Client Credentials Flow. The Application is meant to be a non-person entity within the system. Applications are meant for system to system communication via a web API.
A Client is an actor tha can initiate an Authorization Code Flow. The Client represents a system that requires Users to authenticate. For instance a mobile application, an SPA, or a client side rendered web application.
Is the entity that an Authorization Code can be generated for. A user has a username and a password that can be exchanged for an Authorization Code via a Client.
The Profile is used to hold metadata about the actor. This data can be mapped to the claims of the JWT. The Profile is associated with an Actor via the Actors id. The Profile also has a type of either User or Application.
The Application Secret is the client_secret in OAuth terms. An Application can have multiple secrets and each secret can be associated with a different set of Scopes.
The SingingKey is a private/public keypair associated with the AuthorizationServer. The public keys will be included in the JWKS. Multiple keys can exist for each AuthorizationServer.
A standard OAuth Scope. They can be associated with a Client or an ApplicationSecret and will be included in the JWT if requested in the OAuth Code flow.
A Template is a stored document that can be rendered for particular actions against the Authorization Server. For instance the login screen must have a template defined for the Authorization Server. A password reset email could also have a Template associate (does not as of this commit.)
This project uses Quarkus, the Supersonic Subatomic Java Framework.
If you want to learn more about Quarkus, please visit its website: https://quarkus.io/ .
You can run your application in dev mode that enables live coding using:
./gradlew quarkusDevNOTE: Quarkus now ships with a Dev UI, which is available in dev mode only at http://localhost:8080/q/dev/.
The application can be packaged using:
./gradlew buildIt produces the quarkus-run.jar file in the build/quarkus-app/ directory.
Be aware that it’s not an über-jar as the dependencies are copied into the build/quarkus-app/lib/ directory.
The application is now runnable using java -jar build/quarkus-app/quarkus-run.jar.
If you want to build an über-jar, execute the following command:
./gradlew build -Dquarkus.package.type=uber-jarThe application, packaged as an über-jar, is now runnable using java -jar build/*-runner.jar.
You can create a native executable using:
./gradlew build -Dquarkus.package.type=nativeOr, if you don't have GraalVM installed, you can run the native executable build in a container using:
./gradlew build -Dquarkus.package.type=native -Dquarkus.native.container-build=trueYou can then execute your native executable with: ./build/code-with-quarkus-1.0.0-SNAPSHOT-runner
If you want to learn more about building native executables, please consult https://quarkus.io/guides/gradle-tooling.
Easily start your Reactive RESTful Web Services