<!--
Describe the big picture of your changes here to communicate to the
maintainers why we should accept this pull request.
This text will be included in the changelog. If applicable, include
links to documentation or pieces of code.
If your change includes breaking changes please add a code block
documenting the breaking change:
```
BREAKING CHANGES: This patch changes the behavior of configuration item `foo` to do bar. To keep the existing
behavior please do baz.
```
-->
## Related issue(s)
<!--
If this pull request
1. is a fix for a known bug, link the issue where the bug was reported
in the format of `#1234`;
2. is a fix for a previously unknown bug, explain the bug and how to
reproduce it in this pull request;
3. implements a new feature, link the issue containing the design
document in the format of `#1234`;
4. improves the documentation, no issue reference is required.
Pull requests introducing new features, which do not have a design
document linked are more likely to be rejected and take on average 2-8
weeks longer to
get merged.
You can discuss changes with maintainers either in the Github
Discussions in this repository or
join the [Ory Chat](https://www.ory.sh/chat).
-->
## Checklist
<!--
Put an `x` in the boxes that apply. You can also fill these out after
creating the PR.
Please be aware that pull requests must have all boxes ticked in order
to be merged.
If you're unsure about any of them, don't hesitate to ask. We're here to
help!
-->
- [ ] I have read the [contributing
guidelines](../blob/master/CONTRIBUTING.md).
- [ ] I have referenced an issue containing the design document if my
change
introduces a new feature.
- [ ] I am following the
[contributing code
guidelines](../blob/master/CONTRIBUTING.md#contributing-code).
- [ ] I have read the [security policy](../security/policy).
- [ ] I confirm that this pull request does not address a security
vulnerability. If this pull request addresses a security vulnerability,
I
confirm that I got the approval (please contact
[security@ory.sh](mailto:security@ory.sh)) from the maintainers to push
the changes.
- [ ] I have added tests that prove my fix is effective or that my
feature
works.
- [ ] I have added or changed [the
documentation](https://github.com/ory/docs).
## Further Comments
<!--
If this is a relatively large or complex change, kick off the discussion
by explaining why you chose the solution
you did and what alternatives you considered, etc...
-->
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 commit addresses several occurrences where 'strategy' was
misspelled as 'stragegy' throughout the codebase.
Additionally, a similar issue was found and corrected in the Ory
documentation repository (ory/docs), with a corresponding pull request
submitted.
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
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.
The access token type (`jwt` or `opaque`) can now be set in the client configuration. The value set here will overwrite the global value for all flows concerning that client.
This adds a new boolean parameter `skip_consent` to the admin APIs of
the OAuth clients. This parameter will be forwarded to the consent app
as `client.skip_consent`.
It is up to the consent app to act on this parameter, but the canonical
implementation accepts the consent on the user's behalf, similar to
when `skip` is set.
Patrik
shaunn
Henning Perl
hackerman
Philippe Gaultier
Arne Luenser
Nikos Sklikas
Paul
Atsuki Narita
Henning Perl
Kevin Goslar