Releases: panva/node-oidc-provider
v4.2.2
v4.2.1
v4.2.0
New Feature - OAuth 2.0 Web Message Response Mode
Based on OAuth 2.0 Web Message Response Mode response_mode=web_message is a new response mode that uses HTML5 Web Messaging instead of a redirect for the Authorization Response from the Authorization Endpoint. It defines two modes: simple mode and relay mode. Relay mode can be used to protect the response by confining it within the origins of a resource server and preventing it from being read by the client.
This is released as an experimental/draft feature so as with the others it is disabled by default and breaking changes to this feature will be released as MINOR releases. When using Web Message Response Mode be sure to lock down oidc-provider
in your package.json with the tilde ~
operator and pay close attention to this changelog when updates are released.
To enable configure:
const configuration = { features: { webMessageResponseMode: true } };
Note: Although a general advise to use a helmet
(express, koa) it is especially advised for your interaction views routes if Web Message Response Mode is available on your deployment.
Enhancements
- added no-cache headers to the authorization endpoint
#provider.setProviderSession()
now returns the created session object#provider.registerGrantType()
also accepts additional parameter to indicate parameters for which duplicates are allowed (e.g.audience
andresource
in OAuth 2.0 Token Exchange)
Fixes
- fixed some edge cases where authorization error responses would still reach the redirect_uri even when it could not have been validated
- fixed parameters coming from Request Objects to be always used as strings
- fixed upstream body parser params to be always strings (unless json)
- fixed parameters coming multiple times still being used in error handlers (e.g. state)
- fixed form post values not being html escaped
v4.1.3
v4.1.2
v4.1.1
v4.1.0
New Feature - Storage Formats
Added formats
configuration option. This option allows to configure the token storage and value formats. The different values change how a token value is generated as well as what properties get sent to the adapter for storage. Three formats are defined:
legacy
is the current and default format until next major release. no changes in the format sent to adapteropaque
formatted tokens have a different value thenlegacy
and in addition store what was in legacy format encoded underpayload
as root properties, this makes analysing the data in your storage way easierjwt
formatted tokens are issued as JWTs and stored the same asopaque
only with additional propertyjwt
. The signing algorithm for these tokens uses the client'sid_token_signed_response_alg
value and falls back toRS256
for tokens with no relation to a client or when the client's alg isnone
This feature uses the previously defined public token API of [klass].prototype.getValueAndPayload, [klass].prototype.constructor.getTokenId, [klass].prototype.constructor.verify
and adds a new one [klass].prototype.constructor.generateTokenId
. See the inline comment docs for more detail on those. Further format ideas and suggestions are welcome.
New Feature - conformIdTokenClaims
feature toggle
Added conformIdTokenClaims
feature toggle.
This toggle makes the OP only include End-User claims in the ID Token as defined by Core 1.0 section 5.4 - when the response_type is id_token or unless requested using the claims parameter.
Fixes
- fixed edge cases where client and provider signing keys would be used for encryption and vice versa
- fixed client
request_object_signing_alg
andcontact
validations - fixed
defaultHttpOptions
to be as documented - fixed an end_session server error in case where session.authorizations is missing - #295
- adjusted error_description to be more descriptive when PKCE plain value fallback is not possible due to the plain method not being supported
- fixed
audiences
helper results to assert that an array of strings is returned - fixed issues with interaction sessions and the back button, assertions are now in place and both resume endpoint and interaction helpers will now reject with SessionNotFound named error, which is essentially just InvalidRequest with a more descriptive name.
v4.0.3
- fixed token endpoint
grant_type=refresh_token
scope parameter related bugs- a rotated refresh token will retain the original scope, its only the access and id token that
has the requested scope as specified in section 6 of RFC6749 openid
scope must be provided in the list of requested scopes
- a rotated refresh token will retain the original scope, its only the access and id token that
v4.0.2
- fixed non-spec errors
restricted_response_type
andrestricted_grant_type
to be UnauthorizedClient (unauthorized_client
) instead as specified in RFC6749 - fixed missing
WWW-Authenticate
response header in Bearer auth scheme endpoints when 401 is returned (was missing fromregistration_endpoint
,registration_client_uri
) - fixed
#session.save()
whencookies.*.maxAge
is set to0
to not add theexp
claim - #289 - fixed the
remember=false
option to apply to client session state cookies too
v4.0.1
Breaking changes
- minimal version of node lts/carbon is required (>=8.9.0)
- Client Metadata - null property values are no longer ignored
- clients pushed through
#initialize()
must not submit properties with null values - clients stored via an adapter must be updated in your storage not to have null or
null-deserialized values, alternatively you can update your adapter not to return these
properties back to the provider
const _ = require('lodash'); // your adapter implementation class MyAdapter { // ... async find(id) { // load entity properties and then drop the null properties if its a Client adapter instance // this is implementation specific const data = await DB.query(...); if (this.name === 'Client') { return _.omitBy(data, _.isNull); } return data; } // ... }
- clients pushed through
- Client Authentication
- Errors related to authentication details parsing and format are now
400 Bad Request
and
invalid_request
. Errors related to actual authentication check are now401 Unauthorized
and
invalid_client
with no details in the description.
This means that errors related to client authentication will no longer leak details back to the
client, instead the provider may be configured to get these errors from e.g.
provider.on('grant.error')
and provide the errors to clients out of bands.function handleClientAuthErrors(err, { headers: { authorization }, oidc: { body, client } }) { if (err instanceof Provider.errors.InvalidClientAuth) { // save error details out-of-bands for the client developers, `authorization`, `body`, `client` // are just some details available, you can dig in ctx object for more. console.log(err); } } provider.on('grant.error', handleClientAuthErrors); provider.on('introspection.error', handleClientAuthErrors); provider.on('revocation.error', handleClientAuthErrors);
- added
WWW-Authenticate
response header to token endpoints when 401 is returned and Authorization
scheme was used to authenticate and changed client authentication related errors to be401 Unauthorized
- fixed several issues with token client authentication related to
client_id
lookup, it is no longer
possible to:- submit multiple authentication mechanisms
- send Authorization header to identify a
none
authentication method client - send both Authorization header and client_secret or client_assertion in the body
- Errors related to authentication details parsing and format are now
- all error classes the provider emits/throws are now exported in
Provider.errors[class]
instead of
Provider[class]
and the class names are no longer suffixed byError
. Seeconsole.log(Provider.errors)
- removed the non-spec
rt_hash
ID Token claim features.pkce
now only enablesS256
by default, this is sufficient for most deployments. If
plain
is needed enable pkce with{ features: { pkce: { supportedMethods: ['plain', 'S256'] } }
.client.backchannelLogout
no longer suppresses any errors, instead rejects the promise- token introspection endpoint no longer returns the wrong
token_type
claim - #189- to continue the support of this non-standardized claim from introspection you may register the following middleware
provider.use(async function introspectionTokenType(ctx, next) { await next(); if (ctx._matchedRouteName === 'introspection') { const token = ctx.oidc.entities.AccessToken || ctx.oidc.entities.ClientCredentials || ctx.oidc.entities.RefreshToken; switch (token && token.kind) { case 'AccessToken': ctx.body.token_type = 'access_token'; break; case 'ClientCredentials': ctx.body.token_type = 'client_credentials'; break; case 'RefreshToken': ctx.body.token_type = 'refresh_token'; break; } } });
- to continue the support of this non-standardized claim from introspection you may register the following middleware
- fetched
request_uri
contents are no longer cached for 15 minutes default, cache headers are
honoured and responses without one will fall off the LRU-Cache when this one is full audiences
is now in addition to existingid_token
and signeduserinfo
cases called forclient_credentials
andaccess_token
, this is useful for pushing additional audiences
to an Access Token, these are now returned by token introspection and can be used when serializing
an Access Token as a JWT- the provider will no longer use the first value from
acrValues
to denote a "session" like acr.
In cases where acr is requested as a voluntary claim and no result is available this claim will
not be returned.- to continue the support of the removed behaviour you can change the OIDCContext acr getter
const _ = require('lodash'); const sessionAcr = '...'; Object.defineProperty(provider.OIDCContext.prototype, 'acr', { get() { return _.get(this, 'result.login.acr', sessionAcr); }, });
- removed deprecated
#provider.setSessionAccountId()
helper method. Use#provider.setProviderSession()
instead
- to continue the support of the removed behaviour you can change the OIDCContext acr getter
Enhancements
- Session Changes
- stored sessions now have an
exp
property allowing the provider to ignore expired but
still returned sessions- existing sessions without this property will be accepted and the exp property will be added
with the next save
- existing sessions without this property will be accepted and the exp property will be added
- stored sessions now have an
- bumped the semantic version of every dependency to the latest as of release
- added
aud
to the introspection response if a token has one audiences
helper gets called with additional parametersuse
andscope
renderError
helper is now called with a third argument that's the actual Error instance.node-jose
dependency bumped to major ^1.0.0 - fixesA\d{3}GCMKW
symmetrical encryption support- added
cookies.thirdPartyCheckUrl
option and a warning to host it - moved middleware handling missing optionally
redirect_uri
parameter case right after loading
the client