Ory Hydra now supports a `registration` value for the `prompt` parameter of
the authorization request. When specifying `prompt=registration`, Ory Hydra
will redirect the user to the URL found under `urls.registration`
(instead of `urls.login`).
This patch changes the primary key of the `hydra_client` table. We do not expect issues, as that table is probably not overly huge in any deployment. We do however highly recommend to test the migration performance on a staging environment with a similar database setup.
This patch optimizes the performance of authorization code grant flows by minimizing the number of database queries. We acheive this by storing the flow in an AEAD-encoded cookie and AEAD-encoded request parameters for the authentication and consent screens.
BREAKING CHANGE:
* The client that is used as part of the authorization grant flow is stored in the AEAD-encoding. Therefore, running flows will not observe updates to the client after they were started.
* Because the login and consent challenge values now include the AEAD-encoded flow, their size increased to around 1kB for a flow without any metadata (and increases linearly with the amount of metadata). Please adjust your ingress / gateway accordingly.
Added a generic token hook that is called for all grant types and includes `payload` with a single allowed value - `assertion` to cover the `jwt-bearer` grant type customization.
The existing `refresh token hook` is left unchanged and is considered to be deprecated in favor of the new hook logic. The `refresh token hook` will at some point be removed.
Closes#3244
Closes https://github.com/ory/fosite/issues/729
This change introduces a new endpoint that allows you to control how long client tokens last. Now you can configure the lifespan for each valid combination of Client, GrantType, and TokenType.
See #3157
Co-authored-by: aeneasr <3372410+aeneasr@users.noreply.github.com>
Co-authored-by: Andreas Bucksteeg <andreas@bucksteeg.de>
BREAKING CHANGE: This release updates SDK services from `public` and `admin` to `v2`. Methods exposed at the admin interface are now prefixed with `admin` (e.g. `adminCreateOAuth2Client`). Administrative endpoints now have an `/admin` prefix (e.g. `POST /admin/clients`). Existing administrative endpoints will redirect to this new prefixed path for backwards compatibility.
This patch adds support for hashing client secrets using pbkdf2 instead of bcrypt, which might be a more appropriate algorithm in certain settings. As we assume that most environments fall in this category, we also changed the default to pbkdf2 with 25.000 rounds (roughly 1-3ms per hash on an Apple M1 Max core).
High hash costs are needed when hashing user-chosen passwords, as users often reuse passwords across sites. A high hash cost will make it much harder for the attacker to guess the user-chosen password and try using it on other sites (e.g. Google).
As most client secrets are auto-generated, using high hash costs is not useful. The password (OAuth2 Client Secret) is not user chosen and unlikely to be reused. As such, there is little point in using excessive hash costs to protect users. High hash costs in a system like Ory Hydra will cause high CPU costs from mostly automated traffic (OAuth2 Client interactions). It has also been a point of critizism from some who wish for better RPS on specific endpoints.
Other systems like Keycloak do not [hash client secrets at all](https://groups.google.com/g/keycloak-dev/c/TmsNfnol0_g), referencing more secure authentication mechanisms such as assertion-based client authentication.
We and the IETF disagree though, as [rfc6819#section-5.1.4.1.3](https://datatracker.ietf.org/doc/html/rfc6819#section-5.1.4.1.3) states:
> The authorization server should not store credentials in clear text.
Typical approaches are to store hashes instead or to encrypt
credentials. If the credential lacks a reasonable entropy level
(because it is a user password), an additional salt will harden the
storage to make offline dictionary attacks more difficult.
For that reason, cleartext storage of client secrets is not going to be supported.
BREAKING CHANGE: This change is backwards compatible, but changes the default hashing algorithm to PBKDF2. To keep using BCrypt for hashing new OAuth2 Client Secrets set the following configuration option in your configuration file:
```
oauth2:
hashers:
algorithm: bcrypt
```
BREAKING CHANGE: To improve security and scalability (in particular sharding), OAuth 2.0 Client IDs can no longer be chosen but are always assigned a random generated UUID V4. OAuth 2.0 Clients created with custom IDs before the v2.0 release will continue working with their legacy Client ID in Ory Hydra v2.x.
Additionally, the `hydra create client` command no longer supports flag `--id` and flag `--callbacks` has been renamed to `--redirect-uris`.
Closes#2911
This change introduces a new endpoint that allows you to control how long client tokens last. Now you can configure the lifespan for each valid combination of Client, GrantType, and TokenType.
See #3157
Co-authored-by: aeneasr <3372410+aeneasr@users.noreply.github.com>
Co-authored-by: Andreas Bucksteeg <andreas@bucksteeg.de>
This patch adds a new feature to Ory Hydra which allows the updating of access and ID tokens during the refresh flow. To set it up, use the `oauth2.refresh_token_hook` configuration to set up a HTTP(S) endpoint which receives a POST request when a refresh token is about to be issued.
Closes#2570
Co-authored-by: hackerman <3372410+aeneasr@users.noreply.github.com>
This patch adds support for Refresh Token reuse Detection introduced by https://github.com/ory/fosite/pull/567. Ory Hydra's persister no longer deletes refresh tokens when using them, but instead deactivates them - similar to how authorization codes work.
Closes#2022
Henning Perl
Patrik
Arne Luenser
Serhii Halchenko
hackerman
Kevin Goslar
Ferdynand Naczynski
Grant Zvolsky
Zach Abney
Stepan Rakitin
Felix Jung
Nestor