Skip to content

Releases: panva/node-oidc-provider

v4.2.2

13 Jul 18:10
Compare
Choose a tag to compare
  • fixed expiresIn sent to adapter#upsert when interaction session are saved using interactionFinished()

v4.2.1

13 Jul 08:48
Compare
Choose a tag to compare
  • fixed form_post regression for response types including token from 4.2.0

v4.2.0

12 Jul 17:15
Compare
Choose a tag to compare

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

28 Jun 18:56
Compare
Choose a tag to compare
  • fixed www-authenticate header uses in bearer token endpoints according to Core 1.0 and RFC6750

v4.1.2

26 Jun 13:18
Compare
Choose a tag to compare
  • fixed missing sid claim in access tokens
  • fixed non-consumable tokens having consumed stored and #consume() instance method

v4.1.1

25 Jun 16:44
Compare
Choose a tag to compare
  • fixed missing sub claim from tokens when using the jwt format

v4.1.0

22 Jun 12:42
Compare
Choose a tag to compare

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

09 Jun 20:15
Compare
Choose a tag to compare
  • 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

v4.0.2

05 Jun 08:06
Compare
Choose a tag to compare
  • fixed non-spec errors restricted_response_type and restricted_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 from registration_endpoint, registration_client_uri)
  • fixed #session.save() when cookies.*.maxAge is set to 0 to not add the exp claim - #289
  • fixed the remember=false option to apply to client session state cookies too

v4.0.1

01 Jun 11:41
Compare
Choose a tag to compare

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;
      }
      // ...
    }
  • 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 now 401 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 be 401 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
  • 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 by Error. See console.log(Provider.errors)
  • removed the non-spec rt_hash ID Token claim
  • features.pkce now only enables S256 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;
          }
        }
      });
  • 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 existing id_token and signed userinfo
    cases called for client_credentials and access_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

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
  • 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 parameters use and scope
  • renderError helper is now called with a third argument that's the actual Error instance.
  • node-jose dependency bumped to major ^1.0.0 - fixes A\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