v4.3.1

Bug Fixes

• device_authorization w/ offline_access scope (19a85ac)

v4.3.0

Bug Fixes

• allow for pkce to be disabled (3aca2c8)
• debug revocation after yield (bf4c012)
• pathFor returns a valid route for issuers with terminating "/" (9e4b1a0), closes #315

Features

• add Device Flow experimental/draft feature (461a8e3)
• add gty storage claim for access and refresh token (a492a5e)
• change the requests's uuid to a previous value of grantId (28673e2)

v4.2.2

• fixed expiresIn sent to adapter#upsert when interaction session are saved using interactionFinished()

v4.2.1

• fixed form_post regression for response types including token from 4.2.0

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 and resource 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

• fixed www-authenticate header uses in bearer token endpoints according to Core 1.0 and RFC6750

v4.1.2

• fixed missing sid claim in access tokens
• fixed non-consumable tokens having consumed stored and #consume() instance method

v4.1.1

• fixed missing sub claim from tokens when using the jwt format

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 adapter
• opaque formatted tokens have a different value then legacy and in addition store what was in legacy format encoded under payload as root properties, this makes analysing the data in your storage way easier
• jwt formatted tokens are issued as JWTs and stored the same as opaque only with additional property jwt. The signing algorithm for these tokens uses the client's id_token_signed_response_alg value and falls back to RS256 for tokens with no relation to a client or when the client's alg is none

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 and contact 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