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.
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.
BREAKING CHANGE: The `iss` (issuer) value no longer appends a trailing slash but instead uses the raw value set in the config.
Setting
```yaml
urls:
self:
issuer: https://auth.example.com
```
has changed
```patch
- "iss": "https://auth.example.com/"
+ "iss": "https://auth.example.com"
```
To set a trailing slash make sure to set it in the config value:
```yaml
urls:
self:
issuer: https://auth.example.com/
```
Closes#1482
BREAKING CHANGES: After battling with [spf13/viper](https://github.com/spf13/viper) for several years we finally found a viable alternative with [knadh/koanf](https://github.com/knadh/koanf). The complete internal configuration infrastructure has changed, with several highlights:
1. Configuration sourcing works from all sources (file, env, cli flags) with validation against the configuration schema, greatly improving developer experience when changing or updating configuration.
2. Configuration reloading has improved significantly and works flawlessly on Kubernetes.
3. Performance increased dramatically, completely removing the need for a cache layer between the configuration system and ORY Hydra.
4. It is now possible to load several config files using the `--config` flag.
5. Configuration values are now sent to the tracer (e.g. Jaeger) if tracing is enabled.
Please be aware that deprecated configuration flags have finally been removed with this change. It is also possible that ORY Hydra might complain about an invalid configuration, because the validation process has improved significantly.
This patch replaces the existing SQL and memory managers with a pop based persister. Existing SQL migrations are compatible as they have been migrated to the new SQL abstraction in version 1.7.x. As a goodie, ORY Hydra now supports SQLite for both in-memory as well as on-disk (useful for development and very small deployments) databases!
Closes#1730
Co-authored-by: aeneasr <aeneas@ory.sh>
Co-authored-by: hackerman <3372410+aeneasr@users.noreply.github.com>
This patch deprecates the previous migration system (sql-migrate) in favor of gobuffalo/fizz. No functional changes have been made.
BREAKING CHANGES: Please run `hydra migrate sql` before applying this release.
This patch significantly refactors internal configuration and service management with the goal of making configuration changes possible without service restarts. This patch prepares the possibility to configure ORY Hydra from a remote source (etcd, consul) and watch for changes. This patch also introduces the possibility to configure ORY Hydra from a configuration file on top of environment variables.
The following issues have been fixed as well:
- Key rotation of the system secret is now much simpler (closes#1316)
- Database connectivity parameters such as max_conns no longer cause issues with older postgres versions (closes#1327)
- Non-existing routes now return a JSON error instead of `text/plain` when `application/json` was requested (clsoes #1244)
- We now push tags latest, X, X.Y, X.Y.Z to docker hub (closes#1289)
- The quickstart guide no longer builds the source code but instead pulls latest tag (closes#1309)
- We moved to goreleaser and godownloader for release management (closes#1107)
- The quickstart Docker Compose files are now reusable (closes#1196)
The following issues are also resolved:
- Closes#1121
Signed-off-by: aeneasr <aeneas@ory.sh>
Field `allowed_cors_origins` was added to OAuth 2.0 Clients. It enables
CORS for the whitelisted URLS for paths which clients interact with,
such as /oauth2/token.
Closes#975
Signed-off-by: arekkas <aeneas@ory.am>
This patch introduces two ports, public and administrative. The public
port is responsible for handling API requests to public endpoints such
as /oauth2/auth, while the administrative port handles requests to
JWK, OAuth 2.0 Client, and Login & Consent endpoints.
Closes#904
Signed-off-by: arekkas <aeneas@ory.am>
This patch adds the (experimental) ability to issue JSON Web Tokens instead of ORY Hydra's opaque access tokens. Please be aware that this feature has had little real-world and unit testing and may not be suitable for production.
Simple integration tests using the JWT strategy have been added to ensure functionality.
To use the new JWT strategy, set environment variable `OAUTH2_ACCESS_TOKEN_STRATEGY` to `jwt`. For example: `export OAUTH2_ACCESS_TOKEN_STRATEGY=jwt`.
Please be aware that we (ORY) do not recommend using the JWT strategy for various reasons. If you can, use the default and recommended "opaque" strategy instead.
Closes#248
Signed-off-by: arekkas <aeneas@ory.am>
We have learned a lot over the last year in terms of how ORY Hydra is being used. Initially, we wanted to avoid the problems facing popular databases like MongoDB or others, which did not include authentication for their management APIs.
For this reason, the Warden API was born and primarily used internally and exposed via HTTP. We learned that access control policies are well received, but also add additional complexity to understanding the software. While we firmly believe that these policies implement best practices for access control in complex systems, we do understand that they add a barrier to getting started with ORY Hydra.
For this reason we are planning on moving the Warden API from this project to ORY Oathkeeper or potentially it's own server. We would add a migration path for existing policy definitions to the new service. The default docker image would combine the services in such a way, that ORY Hydra is protected. We would additionally have an (insecure) docker image without authentication which can be used for testing.
This also opens up the possibility of having more access control mechanisms than access control policies. For example, we can add ACL and RBAC and other mechanisms too.
First I think it makes good sense to move this functionality into a separate service and remove the warden calls internally completely. The reason being that not everyone wants to rely on Hydra's access control. Sometimes it's enough to use a gateway in front and require e.g. an API key for management or whatever. New adopters are always baffled by complexity involved with policies and scopes. Removing that from the core could really help. The user survey has also shown that this stuff is quite complex to grasp.
The idea is to have a separate service which is basically ladon as a HTTP API. I think it makes sense to add some functionality to resolve access tokens so it would basically be very similar to the current warden API - probably even equal. There would definitely be some backup mode where hydra's database tables and migrations are used as to make migration as easy as possible.
Then, we would ship docker images and example set ups where different configurations are shown. One of the configurations would be the current one, so basically what we have now in hydra but with the three services combined in one image.
Closes#807
Henning Perl
Arne Luenser
hackerman
Kevin Goslar
Grant Zvolsky
Patrik
aeneasr
arekkas
Amir Aslaminejad
Aeneas