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>
Environment variable `OIDC_DYNAMIC_CLIENT_REGISTRATION_DEFAULT_SCOPE` was added in order to better implement the OpenID Connect Dynamic Client Registration protocol. The mentioned protocol does not support the concept of whitelisting OAuth 2.0 Scope on a per-client basis. Therefore, the functionality to define the default OAuth 2.0 Scope has been defined.
Keep in mind that exposing the OpenID Connect Dynamic Client Registration functionality to the public effectively disables the OAuth 2.0 Scope whitelisting functionality, as each caller of that API can define which OAuth 2.0 Scope a client may request.
If you decide to expose that functionality, you should NEVER assume that the granted OAuth 2.0 Scope has any meaning when handling requests at your consent endpoint, or when validating requests with tokens issued by the client_credentials flow.
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
Previously a newly created public client had a secret send with the initial response and this secret was displayed in the CLI.
Now it is clear that there is no secret needed for public clients. It is not displayed in the CLI anymore.
Closes#737
Previously, clients were created despite an error which said that the secret was too short. This patch changes that and improves error output in the CLI as well for this command.
Closes#725
* oauth2: scopes should be separated by %20 and not +, to ensure javascript compatibility - closes#277
* oauth2/introspect: make endpoint rfc7662 compatible - closes#289
* warden: make it clear that ladon.Request.Subject is not required or break bc and remove it - closes#270
* travis: execute gox build only when new commit is a new tag - closes#285
* docs: improve introduction (#267)
* core: (health) monitoring endpoint - closes#216
* oauth2/introspect: make endpoint rfc7662 compatible - closes#289
* connections: remove connections API - closes#265
* oauth2: token revocation endpoint - closes#233
* vendor: update to fosite 0.5.0
* core: add sql support #292
* connections: remove connections API - closes#265
* all: coverage report is missing covered lines of nested packages - closes#296
* cmd: prettify the `hydra token user` output - closes#281
* travis: make it possible for travis-ci to build forked repos - closes#295
hackerman
RikiyaFujii
Amir Aslaminejad
arekkas
aeneasr
zepatrik
Aeneas