This patch introduces the OAuth 2.0 Device Authorization Grant to Ory
Hydra. The OAuth 2.0 device authorization grant is designed for
Internet-connected devices that either lack a browser to perform a
user-agent-based authorization or are input constrained to the extent
that requiring the user to input text in order to authenticate during
the authorization flow is impractical. It enables OAuth clients on such
devices (like smart TVs, media consoles, digital picture frames, and
printers) to obtain user authorization to access protected resources by
using a user agent on a separate device.
The OAuth 2.0 Device Authorization Grant may also become relevant for AI
Agent authentication flows and is generally an amazing step and
innovation for this project.
A very special thanks goes to @nsklikas from
[Canonical](https://canonical.com), @supercairos from
[shadow.tech](https://shadow.tech) and @BuzzBumbleBee.
For more details, please check out the documentation
(https://github.com/ory/docs/pull/2026)
To implement this feature, you will need to implement two additional
screens in your login and consent application. A reference
implementation can be found
[here](99ca6ad544/src/routes/device.ts).
Closes#3851Closes#3252Closes#3230Closes#2416
This is a follow-up to #3932.
This makes several improvements, chiefly restoring backwards
compatibility to Hydra before #3932. We now return both the `challenge`
as well as the `consent_request_id` from our APIs and distinguish
between them clearly.
Closes#3941
This change adds the ability to revoke token chains by "consent
challenge ID".
## "Consent sessions"
Each time the user goes through a `GET
/oauth2/auth?response_type=code&...` auth code flow, we persist a new
"consent session" to the database.
This is independent of whether the user has previously logged in and/or
granted consent, or whether the user was actively asked to grant consent
by the consent app. A successful journey through the auth code flow
results in a new "consent session".
This consent session is uniquely identified by its "consent challenge
ID". This ID is obtained from the [`GET
/admin/oauth2/auth/requests/consent?consent_challenge=...`](https://www.ory.sh/docs/reference/api#tag/oAuth2/operation/getOAuth2ConsentRequest)
API. Note that it is not the same as the `consent_challenge=...` query
parameter!
Any access and refresh tokens obtained from a token exchange following
that particular user journey are bound to that consent session.
We call the totality of all refresh+access tokens derived from a
particular consent session a "token chain".
## Token revocation
Revoking an access token (AT) is simple: send the AT to `/oauth2/revoke`
and it is revoked. If this AT was derived from a refresh token (RT), the
parent RT is not revoked.
Revoking a refresh token (RT) also revokes associated access tokens.
## Revocation by consent challenge ID
During an authorization code flow, save the consent challenge ID into
the access token session data:
```
GET /admin/oauth2/auth/requests/consent?consent_challenge=abcdef
```
Response:
```
{
"acr": ...,
"challenge": "G_TIM3XABG14UwIgDoT1DRfipjhC1uix" # <- this is the ID we need
...
}
```
Accept the consent request:
```
PUT /admin/oauth2/auth/requests/consent/accept?consent_challenge=abcdef
{
"remember": true,
"remember_for": 3600,
"session": {
"access_token": {
"ccid": "G_TIM3XABG14UwIgDoT1DRfipjhC1uix"
}
},
...
}
```
To revoke the token chain associated with this consent challenge ID, use
```
POST admin/oauth2/auth/sessions/consent?consent_challenge_id=G_TIM3XABG14UwIgDoT1DRfipjhC1uix
```
This patch improves Ory Hydra's ability to deal with refresh flows which, for example, concurrently refresh the same token. Furthermore, graceful token refresh has been improved to handle a variety of edge cases and scenarios.
Additionally, serializability errors in CockroachDB are now correctly retried.
See https://github.com/ory-corp/cloud/issues/7311
Closes https://github.com/ory/hydra/pull/3895
Resolves a deviation from the OpenID Connect spec, where the `redirect_uri` was not required when performing flows with `scope=openid`.
BREAKING CHANGE: Going forward, OAuth2 Clients requesting an OpenID Connect flow **must** include the `redirect_uri` parameter or the request will be rejected.
This patch adds a configuration flag which enables graceful refresh token rotation. Previously, refresh tokens could only be used once. On reuse, all tokens of that chain would be revoked.
This is particularly challenging in environments, where it's difficult to make guarantees on synchronization. This could lead to refresh tokens being sent twice due to some parallel execution.
To resolve this, refresh tokens can now be graceful by changing `oauth2.grant.refresh_token.grace_period=10s` (example value). During this time, a refresh token can be used multiple times to generate new refresh, ID, and access tokens.
All tokens will correctly be invalidated, when the refresh token is re-used after the grace period expires, or when the delete consent endpoint is used.
Closes#1831#3770
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
Patrik
Nikos Sklikas
Arne Luenser
hackerman
Henning Perl
Serhii Halchenko
Kevin Goslar
Ferdynand Naczynski
Grant Zvolsky
Zach Abney