NewYour coding agent can read the release notes before it upgrades.Set up the MCP server →
Go modules · #178 by repository stars
Last release 4 years ago
no release in 18 months
Ships fairly regularly
a new release about every 9 days
Nearly every release is documented
notes for 55 of the last 60 stable releases
Nothing withdrawn
no release was ever pulled
11 years old
3599 releases · first in 2015
Nothing published for this version
fix: resolve bugs in config schema
fix: resolve bugs in config schema (#1805)
This patch fixes 6 bugs in the config.schema.json and adds "additionalProperties": false where appropriate.
Closes #1804
Co-authored-by: aeneasr aeneas@ory.sh
Resolve bugs in config schema (#1805) (1f6da12), closes #1804:
This patch fixes 6 bugs in the config.schema.json and adds "additionalProperties": false where appropriate.
Use existing docker versions in quickstart compose (4892a1f)
One column per quarter.
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Use correct packr paths in gitignore
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
fix: return proper error code in refresh and code flows
fix: return proper error code in refresh and code flows (#1800)
Resolves a regression issue which sends an invalid error response when a refresh token is being re-used, is not found, or the wrong client is accessing it.
This patch also bumps jose-related tooling which introduces better security measure against certain types of x509 attacks.
See https://community.ory.sh/t/refresh-token-endpoint-returns-invalid-request-error-expecting-invalid-grant/1637/2 See https://github.com/ory/fosite/pull/426 See https://github.com/ory/fosite/issues/418
consent: Login and consent error handling (#1799) (af18bdb), closes #1791 #1791:
A regression was introduces in 1.4.2 which caused the error handling to misbehave
Return proper error code in refresh and code flows (#1800) (9145e65):
Resolves a regression issue which sends an invalid error response when a refresh token is being re-used, is not found, or the wrong client is accessing it.
This patch also bumps jose-related tooling which introduces better security measure against certain types of x509 attacks.
See https://community.ory.sh/t/refresh-token-endpoint-returns-invalid-request-error-expecting-invalid-grant/1637/2 See https://github.com/ory/fosite/pull/426 See https://github.com/ory/fosite/issues/418
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
chore: move to ory analytics fork
Nothing published for this version
Nothing published for this version
Nothing published for this version
fix: add forgotten error check to test
BREAKING CHANGE: This patch requires a new SQL Table which needs to be created using hydra migrate sql. No other breaking changes have been introduced…
Merge pull request from GHSA-3p3g-vpw6-4w66
BREAKING CHANGE: This patch requires a new SQL Table which needs to be created using hydra migrate sql. No other breaking changes have been introduced by this patch.
This patch introduces a blacklist for JTIs which prevents a potential replay of private_key_jwt JWTs when performing client authorization.
When using client authentication method "private_key_jwt" [1], OpenId specification says the following about assertion jti:
A unique identifier for the token, which can be used to prevent reuse of the token. These tokens MUST only be used once, unless conditions for reuse were negotiated between the parties
Hydra does not seem to check the uniqueness of this jti value. Here is me sending the same token request twice, hence with the same jti assertion, and getting two access tokens:
$ curl --insecure --location --request POST 'https://localhost/_/oauth2/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'grant_type=client_credentials' \
--data-urlencode 'client_id=c001d00d-5ecc-beef-ca4e-b00b1e54a111' \
--data-urlencode 'scope=application openid' \
--data-urlencode 'client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer' \
--data-urlencode 'client_assertion=eyJhb [...] jTw'
{"access_token":"zeG0NoqOtlACl8q5J6A-TIsNegQRRUzqLZaYrQtoBZQ.VR6iUcJQYp3u_j7pwvL7YtPqGhtyQe5OhnBE2KCp5pM","expires_in":3599,"scope":"application openid","token_type":"bearer"}⏎ ~$ curl --insecure --location --request POST 'https://localhost/_/oauth2/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'grant_type=client_credentials' \
--data-urlencode 'client_id=c001d00d-5ecc-beef-ca4e-b00b1e54a111' \
--data-urlencode 'scope=application openid' \
--data-urlencode 'client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer' \
--data-urlencode 'client_assertion=eyJhb [...] jTw'
{"access_token":"wOYtgCLxLXlELORrwZlmeiqqMQ4kRzV-STU2_Sollas.mwlQGCZWXN7G2IoegUe1P0Vw5iGoKrkOzOaplhMSjm4","expires_in":3599,"scope":"application openid","token_type":"bearer"}
We rate the severity as medium because the following reasons make it hard to replay tokens without the patch:
This will be patched with v1.4.0+oryOS.17
Two workarounds have been identified:
private_key_jwthttps://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication
This issue will be resolved in the upstream repository https://github.com/ory/fosite
This patch requires a new SQL Table which needs to be created using hydra migrate sql. No other breaking changes have been introduced by this patch.
This patch introduces a blacklist for JTIs which prevents a potential replay of private_key_jwt JWTs when performing client authorization.
When using client authentication method "private_key_jwt" [1], OpenId specification says the following about assertion jti:
A unique identifier for the token, which can be used to prevent reuse of the token. These tokens MUST only be used once, unless conditions for reuse were negotiated between the parties
Hydra does not seem to check the uniqueness of this jti value. Here is me sending the same token request twice, hence with the same jti assertion, and getting two access tokens:
$ curl --insecure --location --request POST 'https://localhost/_/oauth2/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'grant_type=client_credentials' \
--data-urlencode 'client_id=c001d00d-5ecc-beef-ca4e-b00b1e54a111' \
--data-urlencode 'scope=application openid' \
--data-urlencode 'client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer' \
--data-urlencode 'client_assertion=eyJhb [...] jTw'
{"access_token":"zeG0NoqOtlACl8q5J6A-TIsNegQRRUzqLZaYrQtoBZQ.VR6iUcJQYp3u_j7pwvL7YtPqGhtyQe5OhnBE2KCp5pM","expires_in":3599,"scope":"application openid","token_type":"bearer"}⏎ ~$ curl --insecure --location --request POST 'https://localhost/_/oauth2/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'grant_type=client_credentials' \
--data-urlencode 'client_id=c001d00d-5ecc-beef-ca4e-b00b1e54a111' \
--data-urlencode 'scope=application openid' \
--data-urlencode 'client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer' \
--data-urlencode 'client_assertion=eyJhb [...] jTw'
{"access_token":"wOYtgCLxLXlELORrwZlmeiqqMQ4kRzV-STU2_Sollas.mwlQGCZWXN7G2IoegUe1P0Vw5iGoKrkOzOaplhMSjm4","expires_in":3599,"scope":"application openid","token_type":"bearer"}
We rate the severity as medium because the following reasons make it hard to replay tokens without the patch:
This will be patched with v1.4.0+oryOS.17
Two workarounds have been identified:
private_key_jwthttps://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication
This issue will be resolved in the upstream repository https://github.com/ory/fosite
client: Remove 404 from GET responses (#1746) (6147e11), closes #1744
Force transaction isolation level to LevelRepeatableRead (#1766) (ad7ae00), closes #1719 #1735:
To improve consistency in certain authorization flows that utilize transactions, this PR forces the SQL storage transaction isolation level to LevelRepeatableRead. This will ensure that we avoid the phenomena of non-repeatable reads which occur when a transaction re-reads data it has previously read and then finds out that another transaction has since modified that data and committed. As a result, setting this isolation level fixes a flaw where one could use a given refresh token more than once. See the test added.
In the event that multiple concurrent transactions are competing under a given refresh token workflow, the underlying database engine will eventually return an error when one of the transactions successfully commits. For example, in such a scenario, postgres will rollback the transaction with:
could not serialize access due to concurrent update (SQLSTATE 40001)
sdk: Ignore go-jose when generating swagger spec (#1757) (1388482)
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Your coding agent can read these notes before it upgrades. Set up the MCP server →