NewYour coding agent can read the release notes before it upgrades.Set up the MCP server →
Go modules · #681 by repository stars
Last release 10 months ago
20 Nov 2025
Ships fairly regularly
a new release about every 5 weeks
Nearly every release is documented
notes for 58 of the last 60 stable releases
Nothing withdrawn
no release was ever pulled
11 years old
1103 releases · first in 2015
token/hmac: Add ability to rotate HMAC keys
token/hmac: Add ability to rotate HMAC keys (#298)
Signed-off-by: arekkas aeneas@ory.am
compose: Pass ID Token configuration to strategy
compose: Pass ID Token configuration to strategy (#297)
Resolves an issue where expiry and issuer where not properly configurable in the strategy.
See https://github.com/ory/hydra/issues/985
Signed-off-by: arekkas aeneas@ory.am
One column per quarter.
openid: Validate id_token_hint only via ID claims
openid: Validate id_token_hint only via ID claims (#296)
Signed-off-by: arekkas aeneas@ory.am
Improve token_endpoint_auth_method error message
Improve token_endpoint_auth_method error message (#294)
Signed-off-by: arekkas aeneas@ory.am
Nothing published for this version
Makes error messages easier to debug for end-users
Makes error messages easier to debug for end-users
Makes error messages easier to debug for end-users (5688a1c)
Adds errors for request and registration parameters (920ed71)
Adds OIDC request/request_uri support (c7abcca)
Adds private_key_jwt authentication method (baa4cf1)
Adds proper error responses to request object (f483262)
Disallow empty response_type in request (cf2eb85)
Do not require id_token response type for auth_code (#288) (edc4910):
Before this patch, the id_token response type was required whenever an ID Token was requested. This patch changes that.
Implements oidc compliant response_type validation (f950b9e)
Return unsupported_response_type in validator (a24708e)
Uses JWTStrategy in oauth2.DefaultStrategy (e2d2e75)
Uses JWTStrategy interface in openid.DefaultStrategy (517fdc5), closes #252
This release improves compatibility with the OpenID Connect Dynamic Client Registration 1.0 specification.
response_typesPreviously, when response types such as code token id_token were requested
(OpenID Connect Hybrid Flow) it was enough for the client to have
response_types=["code", "token", "id_token"]. This is however incompatible
with the OpenID Connect Dynamic Client Registration 1.0 spec which dictates that
the response_types have to match exactly.
Assuming you are requesting &response_types=code+token+id_token, your client
should have response_types=["code token id_token"], if other response types
are required (e.g. &response_types=code, &response_types=token) they too
must be included: response_types=["code", "token", "code token id_token"].
openid.DefaultStrategy field name changedField RS256JWTStrategy was renamed to JWTStrategy and now relies on an
interface instead of a concrete struct.
oauth2.RS256JWTStrategy was renamed and field name changedThe strategy oauth2.RS256JWTStrategy was renamed to
oauth2.DefaultJWTStrategy and now accepts an interface that implements
jwt.JWTStrategy instead of directly relying on jwt.RS256JWTStrategy. For
this reason, the field RS256JWTStrategy was renamed to JWTStrategy
private_key_jwt client authentication methodThis patch adds the ability to perform the
private_key_jwt client authentication method
defined in the OpenID Connect specification. Please note that method
client_secret_jwt is not supported because of the BCrypt hashing strategy.
For this strategy to work, you must set the TokenURL field of the
compose.Config object to the authorization server's Token URL.
If you would like to support this authentication method, your Client
implementation must also implement fosite.DefaultOpenIDConnectClient and then,
for example, GetTokenEndpointAuthMethod() should return private_key_jwt.
id_token no longer required for authorize_code flowThe authorize_code
does not require
the id_token response type to be available when performing the OpenID Connect
flow:
grant_types OPTIONAL. JSON array containing a list of the OAuth 2.0 Grant Types that the Client is declaring that it will restrict itself to using. The Grant Type values used by OpenID Connect are:
authorization_code: The Authorization Code Grant Type described in OAuth 2.0 Section 4.1. implicit: The Implicit Grant Type described in OAuth 2.0 Section 4.2. refresh_token: The Refresh Token Grant Type described in OAuth 2.0 Section 6. The following table lists the correspondence between response_type values that the Client will use and grant_type values that MUST be included in the registered grant_types list: code: authorization_code id_token: implicit token id_token: implicit code id_token: authorization_code, implicit code token: authorization_code, implicit code token id_token: authorization_code, implicit If omitted, the default is that the Client will use only the authorization_code Grant Type.
Before this patch, the id_token response type was required whenever an ID
Token was requested. This patch changes that.
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
Allows multipart content type as alternative to x-www-form-urlencoded
openid: Merge duplicate aud claim values
Uses query instead of fragment when handling unsupported response type
Nothing published for this version
oauth2: Resolves several issues related to revokation
oauth2: Resolves several issues related to revokation (#281)
This patch resolves several issues related to token revokation as well as duplicate authorize code usage:
Additionally, this patch resolves an issue where refreshing a token would not revoke previous tokens.
Closes #278 Closes #280
Resolves several issues related to revokation (#281) (72bff7f), closes #278 #280:
This patch resolves several issues related to token revokation as well as duplicate authorize code usage:
Additionally, this patch resolves an issue where refreshing a token would not revoke previous tokens.
Sets audience to a string array (#279) (2d58a58), closes #215
This release implements an OAuth 2.0 Best Practice with regards to revoking already issued access and refresh tokens if an authorization code is used more than one time.
Nothing published for this version
authorize: Fixes implicit detection in error writer
openid: Use claims.RequestedAt for a reference of "now"
openid: Use claims.RequestedAt for a reference of "now" (#276)
Previously, time.Now() was used to get a reference of "now". However, this caused short max_age values to fail if, for example, the consent screen took a long time. This patch now uses the "requested_at" claim value to determine a sense of "now" which should resolve the mentioned issue.
Use claims.RequestedAt for a reference of "now" (#276) (91e7a4c):
Previously, time.Now() was used to get a reference of "now". However, this caused short max_age values to fail if, for example, the consent screen took a long time. This patch now uses the "requested_at" claim value to determine a sense of "now" which should resolve the mentioned issue.
openid: Issue ID Token on implicit code flow as well
openid: Issue ID Token on implicit code flow as well
jwt: Add JTI to counter missing nonce
Nothing published for this version
core: Checks scopes before dispatching handlers
openid: Resolves timing issues in JWT strategy
openid: Resolves timing issues by setting now to the future
openid: Improves validation errors and uses UTC everywhere
openid: Improves prompt, max_age and id_token_hint validation
openid: Improves prompt, max_age and id_token_hint validation (#268)
This patch improves the OIDC prompt, max_age, and id_token_hint validation.
This release improves the OpenID Connect vaildation strategy which now properly
handles prompt, max_age, and id_token_hint at the /oauth2/auth endpoint
instead of the /oauth2/token endpoint.
To achieve this, the OpenIDConnectRequestValidator has been modified and now
requires a jwt.JWTStrategy (implemented by, for example
jwt.RS256JWTStrategy).
The compose package has been updated accordingly. You should not expect any major breaking changes from this release.
openid: Adds a validator used to validate OIDC parameters
oauth2: Introspection should return token type
oauth2: Introspection should return token type (#265)
Closes #264
This patch allows the introspection handler to return the token type (e.g. access_token, refresh_token) of the
introspected token. To achieve that, some breaking API changes have been introduced:
OAuth2.IntrospectToken(ctx context.Context, token string, tokenType TokenType, session Session, scope ...string) (AccessRequester, error) is now OAuth2.IntrospectToken(ctx context.Context, token string, tokenType TokenType, session Session, scope ...string) (TokenType, AccessRequester, error).TokenIntrospector.IntrospectToken(ctx context.Context, token string, tokenType TokenType, accessRequest AccessRequester, scopes []string) (error) is now TokenIntrospector.IntrospectToken(ctx context.Context, token string, tokenType TokenType, accessRequest AccessRequester, scopes []string) (TokenType, error).This patch also resolves a misconfigured json key in the IntrospectionResponse struct. AccessRequester AccessRequester json:",extra" is now properly declared as AccessRequester AccessRequester json:"extra".
core: Regression fix for request ID in refresh token flow
core: Regression fix for request ID in refresh token flow (#262)
Signed-off-by: Beorn Facchini beorn@lade.io
Nothing published for this version
The ExactScopeStrategy performs a simple string match (case sensitive) of scopes.
…by their respective handlers. This lead to two breaking changes in the API:
core: Sanitizes request body before sending it to the storage adapter (#258)
This release resolves a security issue (reported by platform.sh) related to potential storage implementations. This library used to pass all of the request body from both authorize and token endpoints to the storage adapters. As some of these values are needed in consecutive requests, some storage adapters chose to drop the full body to the database. This in turn caused, with the addition of enabling POST-body based client authentication, the client secret to be leaked.
The issue has been resolved by sanitizing the request body and only including those values truly required by their respective handlers. This lead to two breaking changes in the API:
fosite.Requester interface has a new method Sanitize(allowedParameters []string) Requester which returns
a sanitized clone of the method receiver. If you do not use your own fosite.Requester implementation, this won't affect you.CreateAuthorizeCodeSession. The method signatures are as follows:type PKCERequestStorage interface {
GetPKCERequestSession(ctx context.Context, signature string, session fosite.Session) (fosite.Requester, error)
CreatePKCERequestSession(ctx context.Context, signature string, requester fosite.Requester) error
DeletePKCERequestSession(ctx context.Context, signature string) error
}
We encourage you to upgrade to this release and check your storage implementations and potentially remove old data.
We would like to thank platform.sh for sponsoring the development of a patch that resolves this issue.
Sanitizes request body before sending it to the storage adapter (#258) (018b5c1):
This release resolves a security issue (reported by platform.sh) related to potential storage implementations. This library used to pass all of the request body from both authorize and token endpoints to the storage adapters. As some of these values are needed in consecutive requests, some storage adapters chose to drop the full body to the database. This in turn caused, with the addition of enabling POST-body based client authentication, the client secret to be leaked.
The issue has been resolved by sanitizing the request body and only including those values truly required by their respective handlers. This lead to two breaking changes in the API:
fosite.Requester interface has a new method Sanitize(allowedParameters []string) Requester which returns
a sanitized clone of the method receiver. If you do not use your own fosite.Requester implementation, this won't affect you.CreateAuthorizeCodeSession. The method signatures are as follows:type PKCERequestStorage interface {
GetPKCERequestSession(ctx context.Context, signature string, session fosite.Session) (fosite.Requester, error)
CreatePKCERequestSession(ctx context.Context, signature string, requester fosite.Requester) error
DeletePKCERequestSession(ctx context.Context, signature string) error
}
We encourage you to upgrade to this release and check your storage implementations and potentially remove old data.
We would like to thank platform.sh for sponsoring the development of a patch that resolves this issue.
This release resolves a security issue (reported by platform.sh) related to potential storage implementations. This library used to pass all of the request body from both authorize and token endpoints to the storage adapters. As some of these values are needed in consecutive requests, some storage adapters chose to drop the full body to the database.
This implied that confidential parameters, such as the client_secret which can
be passed in the request body since version 0.15.0, were stored as key/value
pairs in plaintext in the database. While most client secrets are generated
programmatically (as opposed to set by the user), it's a considerable security
issue nonetheless.
The issue has been resolved by sanitizing the request body and only including those values truly required by their respective handlers. This lead to two breaking changes in the API:
fosite.Requester interface has a new method
Sanitize(allowedParameters []string) Requester which returns a sanitized
clone of the method receiver. If you do not use your own fosite.Requester
implementation, this won't affect you.CreateAuthorizeCodeSession. A reference implementation can be found
in ./storage/memory.go. The method signatures are as
follows:type PKCERequestStorage interface {
GetPKCERequestSession(ctx context.Context, signature string, session fosite.Session) (fosite.Requester, error)
CreatePKCERequestSession(ctx context.Context, signature string, requester fosite.Requester) error
DeletePKCERequestSession(ctx context.Context, signature string) error
}
We encourage you to upgrade to this release and check your storage implementations and potentially remove old data.
We would like to thank platform.sh for sponsoring the development of a patch that resolves this issue.
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
handler: Adds PKCE implementation for none and S256
handler: Adds PKCE implementation for none and S256 (#246)
This patch adds support for PKCE (https://tools.ietf.org/html/rfc7636) which is used by native apps (mobile) and prevents eavesdropping attacks against authorization codes.
PKCE is enabled by default but not enforced. Challenge method plain is disabled by default. Both settings can be changed using compose.Config.EnforcePKCE and compose.config.EnablePKCEPlainChallengeMethod.
Closes #213
Adds PKCE implementation for none and S256 (#246) (4512853), closes #213:
This patch adds support for PKCE (https://tools.ietf.org/html/rfc7636) which is used by native apps (mobile) and prevents eavesdropping attacks against authorization codes.
PKCE is enabled by default but not enforced. Challenge method plain is disabled by default. Both settings can be changed using compose.Config.EnforcePKCE and compose.config.EnablePKCEPlainChallengeMethod.
introspection: Adds missing http header to response writer
introspection: Adds missing http header to response writer (#247)
The introspection response writer was missing application/json
in header Content-Type. This patch fixes that.
Closes #209
introspection: Decodes of Basic Authorization username/password
introspection: Decodes of Basic Authorization username/password (#245)
Signed-off-by: Dmitry Dolbik dolbik@gmail.com
compose: Makes SendDebugMessages first class citizen
Adds ability to forward hints and debug messages to clients
This patch introduces SendDebugMessagesToClients to the Fosite struct which
enables/disables sending debug information to clients. Debug information may
contain sensitive information as it forwards error messages from, for example,
storage implementations. For this reason, RevealDebugPayloads defaults to
false. Keep in mind that the information may be very helpful when specific OAuth
2.0 requests fail and we generally recommend displaying debug information.
Additionally, error keys for JSON changed which caused a new minor version,
speicifically
statusCode was changed to status_code.
handler/oauth2: Adds offline_access alias for refresh flow
handler/oauth2: Adds offline_access alias for refresh flow
Returns the correct error on duplicate auth code use
Returns the correct error on duplicate auth code use
Improves http error codes ### Unclassified - Improves http error codes
Resolves overriding auth_time with wrong value
Resolves overriding auth_time with wrong value
Your coding agent can read these notes before it upgrades. Set up the MCP server →