Client metadata (#57)

* Aligning `clients.yml` with OAuth terminology
using the keys specified in RFC 7591

* Proper Client Authentication

* Show client information on the consent page

* Necessary Client Authentication Methods, Code refactoring, Better Tests

* Adapted Metadata

* Fixes

* Further Bugfixes

* Rubocop

* Respect `response_mode` in error responses (#54)

* Keep track of metadata during auth flows
This addresses issue #55

* Relocate jwks.json
It is not a .well-known endpoint

* OIDC RP-initiated Logout

* Build Server changes

* Test scripts run with `bundle`

* Fix: User now added to authorization cache

* "If You Want Them to RTFM, Make a Better FM"
Let's give it a try

* Uniform rules for scope checks for all auth grants

* Removed unspecified parameters at token endpoint during code flow

* Fixed default client auth method

* Selfmade CORS

* Removed `allowed_origin` configuration option

* Fix pipeline

* Refactoring and dependency management

* Updated main README

* Documentation Updates and Fixes

* Minor Bugfixes

* Default configuration

Author: bellebaum

.github/workflows/build-server.yml

@@ -25,12 +25,8 @@ jobs:
         rubocop
     - name: Unit tests
       run: |
-        gem install --no-document test-unit rack-test webrick
-        bundle exec ruby tests/test_admin_api.rb
-        bundle exec ruby tests/test_selfservice_api.rb
-        bundle exec ruby tests/test_oauth_helper.rb
-        bundle exec ruby tests/test_oauth2.rb
-        bundle exec ruby tests/test_jwks.rb
+        gem install --no-document test-unit rack-test
+        scripts/test_all.sh
     - name: SBOM generation
       run: |
         gem install --no-document cyclonedx-ruby

.gitignore

@@ -3,3 +3,4 @@
 !/keys/.gitkeep
 /config/*
 /omejdn_priv.*
+/.bundle

Gemfile

@@ -2,23 +2,26 @@
 
 source 'https://rubygems.org'
 
-gem 'abstraction'
-gem 'bcrypt'
-gem 'haml'
-gem 'json'
-gem 'json-jwt'
-gem 'jwt'
-gem 'net-ldap'
-gem 'openssl'
-gem 'rack-test'
-gem 'require_all'
-gem 'rspec'
-gem 'scanf'
-gem 'sinatra'
-gem 'sinatra-activerecord'
-gem 'sinatra-contrib'
-gem 'sinatra-cors'
-gem 'sqlite3'
-gem 'test-unit'
-gem 'thin'
-gem 'webrick'
+# Necessary Gems for Core Omejdn
+group :omejdn do
+  gem 'bcrypt'
+  gem 'haml'
+  gem 'jwt'
+  gem 'openssl'
+  gem 'sinatra'
+  gem 'sinatra-contrib'
+  gem 'thin'
+end
+
+# Necessary Gems for Plugins
+group :plugins do
+  gem 'net-ldap'
+  gem 'sqlite3'
+end
+
+# Development only
+group :development do
+  gem 'rack-test'
+  gem 'rubocop'
+  gem 'test-unit'
+end

Gemfile.lock

@@ -1,78 +1,55 @@
 GEM
   remote: https://rubygems.org/
   specs:
-    abstraction (0.0.4)
-    activemodel (7.0.1)
-      activesupport (= 7.0.1)
-    activerecord (7.0.1)
-      activemodel (= 7.0.1)
-      activesupport (= 7.0.1)
-    activesupport (7.0.1)
-      concurrent-ruby (~> 1.0, >= 1.0.2)
-      i18n (>= 1.6, < 2)
-      minitest (>= 5.1)
-      tzinfo (~> 2.0)
-    aes_key_wrap (1.1.0)
-    bcrypt (3.1.16)
-    bindata (2.4.10)
-    concurrent-ruby (1.1.9)
+    ast (2.4.2)
+    bcrypt (3.1.17)
     daemons (1.4.1)
-    diff-lcs (1.5.0)
     eventmachine (1.2.7)
     haml (5.2.2)
       temple (>= 0.8.0)
       tilt
-    i18n (1.9.1)
-      concurrent-ruby (~> 1.0)
-    json (2.6.1)
-    json-jwt (1.13.0)
-      activesupport (>= 4.2)
-      aes_key_wrap
-      bindata
     jwt (2.3.0)
-    minitest (5.15.0)
     multi_json (1.15.0)
     mustermann (1.1.1)
       ruby2_keywords (~> 0.0.1)
     net-ldap (0.17.0)
     openssl (3.0.0)
+    parallel (1.21.0)
+    parser (3.1.1.0)
+      ast (~> 2.4.1)
     power_assert (2.0.1)
     rack (2.2.3)
-    rack-protection (2.1.0)
+    rack-protection (2.2.0)
       rack
     rack-test (1.1.0)
       rack (>= 1.0, < 3)
-    require_all (3.0.0)
-    rspec (3.10.0)
-      rspec-core (~> 3.10.0)
-      rspec-expectations (~> 3.10.0)
-      rspec-mocks (~> 3.10.0)
-    rspec-core (3.10.2)
-      rspec-support (~> 3.10.0)
-    rspec-expectations (3.10.2)
-      diff-lcs (>= 1.2.0, < 2.0)
-      rspec-support (~> 3.10.0)
-    rspec-mocks (3.10.3)
-      diff-lcs (>= 1.2.0, < 2.0)
-      rspec-support (~> 3.10.0)
-    rspec-support (3.10.3)
+    rainbow (3.1.1)
+    regexp_parser (2.2.1)
+    rexml (3.2.5)
+    rubocop (1.26.0)
+      parallel (~> 1.10)
+      parser (>= 3.1.0.0)
+      rainbow (>= 2.2.2, < 4.0)
+      regexp_parser (>= 1.8, < 3.0)
+      rexml
+      rubocop-ast (>= 1.16.0, < 2.0)
+      ruby-progressbar (~> 1.7)
+      unicode-display_width (>= 1.4.0, < 3.0)
+    rubocop-ast (1.16.0)
+      parser (>= 3.1.1.0)
+    ruby-progressbar (1.11.0)
     ruby2_keywords (0.0.5)
-    scanf (1.0.0)
-    sinatra (2.1.0)
+    sinatra (2.2.0)
       mustermann (~> 1.0)
       rack (~> 2.2)
-      rack-protection (= 2.1.0)
+      rack-protection (= 2.2.0)
       tilt (~> 2.0)
-    sinatra-activerecord (2.0.25)
-      activerecord (>= 4.1)
-      sinatra (>= 1.0)
-    sinatra-contrib (2.1.0)
+    sinatra-contrib (2.2.0)
       multi_json
       mustermann (~> 1.0)
-      rack-protection (= 2.1.0)
-      sinatra (= 2.1.0)
+      rack-protection (= 2.2.0)
+      sinatra (= 2.2.0)
       tilt (~> 2.0)
-    sinatra-cors (1.2.0)
     sqlite3 (1.4.2)
     temple (0.8.2)
     test-unit (3.5.3)
@@ -82,34 +59,24 @@ GEM
       eventmachine (~> 1.0, >= 1.0.4)
       rack (>= 1, < 3)
     tilt (2.0.10)
-    tzinfo (2.0.4)
-      concurrent-ruby (~> 1.0)
-    webrick (1.7.0)
+    unicode-display_width (2.1.0)
 
 PLATFORMS
   x86_64-linux
 
 DEPENDENCIES
-  abstraction
   bcrypt
   haml
-  json
-  json-jwt
   jwt
   net-ldap
   openssl
   rack-test
-  require_all
-  rspec
-  scanf
+  rubocop
   sinatra
-  sinatra-activerecord
   sinatra-contrib
-  sinatra-cors
   sqlite3
   test-unit
   thin
-  webrick
 
 BUNDLED WITH
    2.3.6

HACKING

@@ -0,0 +1,13 @@
+# Commit message format
+
+Please try to use meaningful commit messages.
+
+Think: "Would I understand what was changed when re-reading the commit message
+a few months in the future". If not, then maybe you want to be more verbose.
+
+# Documentation
+
+Pull Requests should aim to update the documentation alongside the code.
+If you do not feel like documenting, because it would take you too long,
+indicate so in your PR and someone else may be able to update the docs
+before the code is merged.

HACKING.md

@@ -4,7 +4,7 @@
 
 ![Omejdn](public/img/logo.jpg)
 
-Omejdn is a minimal but extensible OAuth 2.0/OpenID connect server for ...
+Omejdn is a minimal but extensible OAuth 2.0/OpenID connect server used for ...
 
 1. IoT devices which use their private keys to request OAuth2 access tokens in order to access protected resources
 1. Websites or apps which retrieve user attributes
@@ -16,16 +16,16 @@ Some of Omejdn's core features include:
 
 * Database-free easy-to-read configuration files
 * Integration of existing LDAP directory services
-* Fully configurable through the Admin API Plugin (see API.md)
+* Fully configurable through the Admin API Plugin
 * A User Selfservice API Plugin
+* Standard Compliance (see below)
 
 
 **IMPORTANT**: Omejdn is meant to be a research sandbox in which we can
 (re)implement standard protocols and potentially extend and modify functionality
 under the hood to support research projects.
-It is **NOT** a production grade solution and should not be used as such.
-
-Before updating, please take a look at `release_notes.md` to see if an update requires manual intervention.
+Use at your own risk!
+At a minimum, take a look at the documentation for production setups.
 
 ---
 
@@ -44,6 +44,8 @@ Depending on your use case, you might want to at least configure the following o
 To start Omejdn, simply execute
 
 ```
+$ bundle config set --local with omejdn
+$ bundle config set --local without plugins development # Include these for more complex setups and development
 $ bundle install
 $ ruby omejdn.rb
 ```
@@ -54,10 +56,11 @@ as advertised at `/.well-known/oauth-authorization-server`.
 
 For testing purposes, a script for creating JWT Bearer Tokens for client authentication is located at `scripts/create_test_token.rb`.
 
-**NOTE**: Omejdn does not come with its own TLS server and needs to be run behind a reverse proxy in production setups.
-
 ## Configuration
 
+This section provides but a very brief overview of the possible configuration options.
+When in doubt, take a look at the documentation in `/docs`.
+
 ### Signing keys
 
 The server public/private key pair used to sign tokens is located at `keys/omejdn/omejdn.key`.
@@ -67,31 +70,19 @@ You may place other keys and certificates in this folder to have the keys be adv
 
 ### Clients
 
-Clients are configured in `config/clients.yml`.
-Have a look at the file to see the format.
-
-Confidential clients need to authenticate using a JWT bearer.
-This requires placing a non-expired certificate at `keys/clients/$(base64urlencode(CLIENT_ID)).cert`.
-To have keys be automatically be copied to the correct position, you may specify `import_certfile` for that client in the client configuration file.
-Only confidential clients may use the `client_credentials` grant.
+Clients are configured in `config/clients.yml` using the client registration parameters.
+A minimal public client needs to have
 
-In order to generate your own key pair with a self-signed pulic key
-for testing, your can execute:
-
-    $ openssl req -newkey rsa:2048 -new -nodes -x509 -days 3650 -keyout key.pem -out cert.pem
+- a unique `client_id`
+- a `token_endpoint_auth_method` with a value of `none`
+- at least one value listed under `redirect_uris`
+- at least one value listed under `scope`
 
 ### Users
 
 Users are configured using one or more *User Databases*, or `user_db` plugins.
-Which plugin you need to use depends on your setup, but here is a brief overview:
-
-* `yaml` reads users from a YAML file (`config/users.yml` by default).
-This plugin is useful for semi-static, small sets of users, such as Admin-accounts.
-The configuration format is described in the docs.
-
-* `sqlite` stores users and their attributes in a SQLite3 database. This is useful for larger local sets of users.
-
-* `ldap` Connect to an existing LDAP directory. You will know when to use this.
+Simple setups will probably use the `yaml` plugin, which reads `config/users.yml` by default. Each user has a username, password, and an array of attributes.
+For more complex setups take a look at the documentation.
 
 ### Scopes and Attributes
 
@@ -104,7 +95,7 @@ the `userinfo` endpoint response will also include this attribute.
 Have a look at the `attributes` claim mapper plugin.)
 
 Scopes are granted if the subject contains at least one such attribute.
-Scopes of the form `k:v` are granted if the user contains an attribute with key `k` and value `v`.
+Scopes of the form `k:v` are granted if the user contains an attribute with key `k` and value `v`. See the documentation for details.
 
 In `config/scope_description.yml` you can configure a short description string
 which is displayed to the user in an OpenID Connect flow upon requesting
@@ -121,7 +112,7 @@ There are some special scopes you may want to use:
 ### Plugins
 
 Omejdn's functionality can be customized through the use of plugins.
-For more information please take a look at [the Plugin README](plugins/README.md).
+For more information please take a look at the documentation.
 
 ## Using the Omejdn Docker Image
 
@@ -156,6 +147,7 @@ This server mostly implements the following standards (potentially via plugins):
   * [RFC 9068](https://datatracker.ietf.org/doc/rfc9068/) - JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens
   * [RFC 9101](https://datatracker.ietf.org/doc/rfc9101/) - The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR)
   * [RFC 9126](https://datatracker.ietf.org/doc/rfc9126/) - OAuth 2.0 Pushed Authorization Requests
+  * [RFC 9207](https://datatracker.ietf.org/doc/rfc9207/) - OAuth 2.0 Authorization Server Issuer Identification
 - OpenID Connect Protocol Suite
   * [OpenID Connect Core](https://openid.net/specs/openid-connect-core-1_0.html)
   * [OpenID Connect Discovery](https://openid.net/specs/openid-connect-discovery-1_0.html)
@@ -165,7 +157,7 @@ This server mostly implements the following standards (potentially via plugins):
 - Internet Drafts
   * [draft-spencer-oauth-claims-01](https://www.ietf.org/archive/id/draft-spencer-oauth-claims-01.txt)
   * [draft-ietf-oauth-security-topics-19](https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/)
-  * [draft-ietf-oauth-v2-1-04](https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/)
+  * [draft-ietf-oauth-v2-1-05](https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/)
 
 
 **NOTE**: Omejdn only implements *two* grant types:
@@ -206,6 +198,7 @@ Omejdn uses the following directory structure:
     \_ clients/              (The public key certificates for clients)
 \_ views/                    (Web-Pages)
 \_ public/                   (Additional frontend resources (CSS+Images))
+\_ docs/                     (Documentation)
 \_ tests/
     \_ test_*.rb             (Unit and E2E tests for Omejdn)
     \_ test_resources/       (Test vectors)