### 0.9.0 (18/04/2022)

#### Features

##### Dynamic client registration

`rodauth-oauth` now supports the [Oauth Dynamic client registration RFC](https://datatracker.ietf.org/doc/html/rfc7591), via the `oauth_dynamic_client_registration` feature; it also supports [the OpenID variant](https://openid.net/specs/openid-connect-registration-1_0.html), via the  `oidc_dynamic_client_registration` feature.

With it, you now have the option to enable API-driven client application registration.

##### Client Credentials grant

`rodauth-oauth` now supports the [Client Credentials grant](https://tools.ietf.org/html/rfc6749#section-4.4), via the `oauth_client_credentials_grant` feature.


#### Improvements

##### OAuth Applications & Tokens paginated list pages

The management dashboards for OAuth Applications & Tokens were loading the full dataset into the HTML view. They'll now only show 20 records by default, and present pagination links to navigate across pages (for the default templates).

##### More Oauth Application properties

As a result of implementing "OAuth Dynamic client registration", new functionality is unlocked when the following database columns are set on the oauth applications table:

* `token_endpoint_auth_method` - enables oauth application-scoped verification of used client authentication method.
* `grant_types` - scopes the supported grant types for the given application.
* `response_type` - scopes the supported response types for the given application.
* `logo_uri` - stores an image link which can be used to load and display a logo in the authorization form.
* `tos_uri` - stores a link to the oauth application "Terms of Service" page.
* `policy_uri` - stores a link to the oauth application "Policy" page.
* `jwks_uri` - stores a link where to load the oauth application JWKs from.
* `jwks` - stores the JWKS from the oauth application.
* `contacts` stores the contacts.
* `software_id` - stores the software unique identifier.
* `software_version` - stores the software version for the unique identifier.
* `subject_type` - stores the subject type used for calculating the JWT `sub` claim for the applicatiion.
* `request_object_signing_alg` - stores the signing algorithm which request objects coming from the application will be signed with.
* `request_object_encryption_alg` - stores the encryption algorithm which request objects coming from the application will be encrypted with.
* `request_object_encryption_enc` -  stores the encryption method which request objects coming from the application will be encrypted with.
* `id_token_signed_response_alg` - stores the signing algorithm which id tokens from the application will be signed with.
* `id_token_encrypted_response_alg` - stores the encryption algorithm which id tokens from the application will be encrypted with.
* `id_token_encrypted_response_enc` -  stores the encryption method which id tokens from the application will be encrypted with.
* `userinfo_signed_response_alg` - stores the signing algorithm which JWT-encoded userinfo payloads from the application will be signed with.
* `userinfo_encrypted_response_alg` - stores the encryption algorithm which JWT-encoded userinfo payloads from the application will be encrypted with.
* `userinfo_encrypted_response_enc` -  stores the encryption method which JWT-encoded userinfo payloads from the application will be encrypted with.


##### TTL Store has finer grained lock

The TTL Store, used for the JWKs cache rotation p.ex., had a lock around the section which would involve the HTTP request for the JWKs, which would block the process for the duration of it. The lock has been removed around that area, and if two requests happen for the same URL, first one wins.

#### Deprecations and breaking changes

* (`oauth_jwt` plugin) `:oauth_jwt_algorithm` option default is now `"RS256"` (previous one was `"HS256"`, and yes, this an assymetric cryptography move).
* (`oauth_jwt` plugin) `jws_jwk` option (and all the labels and params) is deprecated.