@bedrock/authn-token - npm Package Versions

11.1.0 - 2023-11-09

Added

• Add feature to enable tester accounts to authenticate into systems using static challenges. If the nonce.testerAccounts config array is populated with one or more objects with id and / or email set to tester account values, then if either of these value is used to create a nonce token, the challenge will always be a static 000000.

11.0.0 - 2023-01-24

Changed

• BREAKING: Use @bedrock/account@9. This update changes the database record and layout for accounts in ways that incompatible with any previous releases.

10.4.0 - 2022-12-30

Changed

• Change internal use of update API for modifying accounts to use replacement vs. patch API. This change should have no impact on the API and should ease the transition to a new @bedrock/account version that no longer supports the patch API.

10.3.1 - 2022-12-11

Fixed

• Ensure account ID is passed to update when updating clients.

10.3.0 - 2022-12-11

Changed

• Require @bedrock/account@8.2 to get latest update API features.
• Use @bedrock/account APIs internally to reduce possibility for breakage if the internals of @bedrock/account change.

Removed

• Non-breaking removal of internal explain flags from APIs that were directly accessing @bedrock/account database collections.
• Non-breaking removal of peer dependency on @bedrock/mongodb because the database is no longer directly accessed.

10.2.0 - 2022-05-28

Added

• Allow default requiredAuthenticationMethods to be configured via a new bedrock configuration option defaultRequiredAuthenticationMethods. If a non-empty array of strings is set as the config option value, then new accounts that do not have any requiredAuthenticationMethods set will receive the value. This feature is backwards compatible and makes no changes by default. It enables applications to avoid having to make an extra call during account registration to setup default required authentication methods.

10.1.0 - 2022-05-22

Changed

• Replace otplib with @digitalbazaar/totp.

10.0.2 - 2022-05-21

Fixed

• Fix salt reuse.

10.0.1 - 2022-05-21

Fixed

• Fix bugs with token expiration code for legacy bcrypt tokens.

10.0.0 - 2022-05-21

Changed

• BREAKING: Include hashParameters in password and nonce tokens. This change should be a mostly backwards compatible change but is marked breaking because it is a data structure change. However, if a password token does not have a hashParameters property, it is assumed to be bcrypt and is internally modified to add matching hashParameters before being returned. If a nonce token does not have a hashParameters property, it is auto-expired. Password / nonce hashing must be performed on the client, so the hash parameters are new information to be sent to the client so it can produce a matching hash.
• BREAKING: If client registration was used in an application previously, clients will need to re-register because prefixed hashes are no longer used internally (to eliminate unnecessary complexity).
• BREAKING: Store fast hashes of token values as binary data instead of as base64 strings. This change should not require any database migration and the code handles old values retrieved from the database that are strings.
• BREAKING: Machine-entry style nonces are no longer slow hashed because it is unnecessary complexity that does not add security. Nonces generated this way and entered this way should be submitted as challenge to be verified, not hash.
• Use of prefixed hashes is now deprecated and its configuration option (hashPrefix) will be removed in a future version. It is an unnecessary complexity that does not add security (given the other design choices).

Removed

• BREAKING: Remove database explain option from most public APIs.
• BREAKING: Remove challenge type. This type was never implemented and can be confused with the option challenge which specifies an unhashed value to be provided when verifying a totp token.
• BREAKING: Remove bcrypt from configuration and as an internally-used slow hash function. Use pbkdf2 instead because it is widely available in clients, especially web browsers -- which is where most slow hashing occurs given the current design.