auth0 / idtoken-verifier Goto Github PK

IdTokenVerifier.getRsaVerifier doesn't return appropriately when there is an error.

The callback is called with an error but execution continues through the function:
https://github.com/auth0/idtoken-verifier/blob/master/src/index.js#L194

I think the function should return after the callback with the error. When the call continues through, it fails and seems to cause my application to halt.

I understand that this is tricky, because this very specific behavior of Azure AD isn't 100% compliant with the Azure AD specifications.

When authenticating with Azure AD, you can restrict access to a specific tenant (by ID or hostname). In this case, everything works as expected. For example, here's the JWKS: https://login.microsoftonline.com/italypaleale.me/discovery/v2.0/keys

However, you can also enable users to authenticate across multiple tenants. In this case, the JWKS is at a specific URL: https://login.microsoftonline.com/organizations/discovery/v2.0/keys

As you can see, inside the JWKS, the issuer contains a non-standard response: https://login.microsoftonline.com/{tenantid}/v2.0. Clients are meant to replace {tenantId} with the tenant of the user that is authenticating.

Because version 2.0 of this library is strictly adhering to the OIDC specs, it broke the scenario above. While I understand that it's an issue on the Azure AD side, I also understand that they don't really have an alternative in their case, if they want to support a multi-tenant service.

Is there a way we can support these edge cases in the library, maybe with a custom callback, or...?

I'm trying to add some new tests to this project via PR #9 but realized that if I want to add a passing test for a new id_token, I'll need it signed with the private key from Auth0.

Is there a way to get access to the secret key and/or could someone with access generate an RS256 signed token from the following that can be verified with the key from https://wptest.auth0.com/:

Header

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "QzE4N0ZBM0VDQzE2RUU0NzI1QzY1MzQ4QTk1MzAwMEI4RDgxNzE4Rg"
}

Payload

{
  "iss": "https://wptest.auth0.com/",
  "sub": "auth0|55d48c57d5b0ad0223c408d7",
  "aud": ["gYSNlU4YC4V1YPdqq8zPQcup6rJw1Mbt", "secondAud"],
  "exp": 1482969031,
  "iat": 1482933031,
  "nonce": "asfd"
}

Thanks!

When the payload of a id_token contains special characters å Æ Ø å é ü æ the decode function does not decode them correctly.

Sample Id Token

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJodHRwOi8vc29tZS1uYW1lc3BhY2UuY29tL3Rlc3QiOiLDpSDDhiDDmCDDpSDDqSDDvCDDpiJ9.sbUwv79yezU_wjJVNO_CfrlpXvblJlrusUxn5290r3s

Payload of the id token.

{
  "http://some-namespace.com/test": "å Æ Ø å é ü æ"
}

Decoded value, but expected the values stated above.

{ 'http://some-namespace.com/test': 'å � � å é ü æ' }

First of all, sorry for the issue with semi-scarce details, but haven't been able to replicate this successfully yet.

I am running automated browser tests with https://www.cypress.io/ and all of our steps start with logging in with auth0-lock. Occasionally (usually if the browser is not active) the GET-request to .well-known.json seems to get aborted, which leads to body being null and the getRsaVerifier throwing at cb(null, new RSAVerifier(keyInfo.modulus, keyInfo.exp)) because keyInfo ends up being null.

I'd assume what happens is that the request gets aborted by superagent, but idtoken-verifier continues verifying the keyInfo regardless of it not being available.

IdTokenVerifier.prototype.getRsaVerifier = function (iss, kid, cb) {
  var _this = this;
  var cachekey = iss + kid;

  if (!this.jwksCache.has(cachekey)) {
    jwks.getJWKS({
      jwksURI: this.jwksURI,
      iss: iss,
      kid: kid
    }, function (err, keyInfo) {
      if (err) {
        return cb(err);
      }
      _this.jwksCache.set(cachekey, keyInfo);
      return cb(null, new RSAVerifier(keyInfo.modulus, keyInfo.exp)); // throws Cannot read property 'modulus' of undefined
    });
  } else {
    var keyInfo = this.jwksCache.get(cachekey); // eslint-disable-line vars-on-top
    cb(null, new RSAVerifier(keyInfo.modulus, keyInfo.exp));
  }
};

Hi, @stevehobbsdev, there is a high severity vulnerability introduced by package crypto-js:

Issue Description

I noticed that a vulnerability is introduced in [email protected]:
Vulnerability SNYK-JS-CRYPTOJS-548472 (high severity) affects package crypto-js (versions:<3.2.1,>=3.3.0 <4.0.0): https://snyk.io/vuln/SNYK-JS-CRYPTOJS-548472
The above vulnerable package is referenced by [email protected] via:
[email protected] ➔ [email protected]

Since [email protected] (51,599 downloads per week) is referenced by 257 downstream projects (e.g., auth0-js 9.16.2 (latest version), auth0-lock 11.30.4 (latest version), @ctx-core/auth0 25.0.44 (latest version), @ctx-core/auth0-ui 10.0.50 (latest version)), the vulnerability SNYK-JS-CRYPTOJS-548472 can be propagated into these downstream projects and expose security threats to them via the following package dependency paths:
(1)[email protected] ➔ @8base-react/[email protected] ➔ @8base-react/[email protected] ➔ @8base/[email protected] ➔ @8base/[email protected] ➔ [email protected] ➔ [email protected] ➔ [email protected]
(2)@al/[email protected] ➔ @al/[email protected] ➔ [email protected] ➔ [email protected] ➔ [email protected]
(3)@corva/[email protected] ➔ [email protected] ➔ [email protected] ➔ [email protected]
......

If idtoken-verifier removes the vulnerable package from the above version, then its fixed version can help downstream users decrease their pain.

Given the large number of downstream users, could you help update your package to remove the vulnerability from [email protected] ?

Fixing suggestions

In [email protected], you can kindly perform the following upgrade :
crypto-js 3.3.0 ➔ 4.0.0;

Note:
[email protected](>=4.0.0) has fixed the vulnerability (SNYK-JS-CRYPTOJS-548472)
Of course, you are welcome to share other ways to resolve the issue.

Thank you for your attention to this issue. ^_^

I have a question (not related to functionality though), on npm I could locate latest version as 2.1.0 while here in release section the latest version I could find is 2.0.3. Am I missing something here ? Just wanted to be sure that I am using the correct version / package.

Would it be possible to add support for proper audience validation when id_token "aud" claim is an array of strings?
Currently the library accepts audience as string and does the exact match, what causes validation to fail.

It should support aud claim as an array

Hi! 👋

Firstly, thanks for your work on this project! 🙂

Today I used patch-package to patch [email protected] for the project I'm working on.

I've noticed IdTokenVerifier constructor accepts string for audience while it probably should accept string or array of strings.

https://github.com/auth0/idtoken-verifier/blob/master/src/index.js#L184-L191

Here is the diff that solved my problem:

diff --git a/node_modules/idtoken-verifier/types/index.d.ts b/node_modules/idtoken-verifier/types/index.d.ts
index 71c1d5e..627cae8 100644
--- a/node_modules/idtoken-verifier/types/index.d.ts
+++ b/node_modules/idtoken-verifier/types/index.d.ts
@@ -33,7 +33,7 @@ export type validateAccessTokenCallback = (err?: Error) => any;
  */
 declare function IdTokenVerifier(parameters: {
   issuer: string;
-  audience: string;
+  audience: string | string[];
   jwksCache?: any;
   jwksURI?: string;
   expectedAlg?: string;
@@ -59,7 +59,7 @@ declare class IdTokenVerifier {
    */
   constructor(parameters: {
     issuer: string;
-    audience: string;
+    audience: string | string[];
     jwksCache?: any;
     jwksURI?: string;
     expectedAlg?: string;

This issue body was partially generated by patch-package.

Description

We've noticed our CI runner has been crashing since the release of version 1.3.0. Error message:

ReferenceError: window is not defined

Since this package is listed on npmjs, I assume there shouldn't be a dependency on window which doesn't exist in node.

The problem is introduced with version 1.3.0 through use of isomophic-unfetch package which depends on the existence of window global:
https://github.com/developit/unfetch/blob/92d9203e02edbd7ac6788be41dd629b5c8247299/packages/isomorphic-unfetch/browser.js#L1

Reverting to v1.2.0 solves the problem for now.

Environment

Please provide the following:

• Version of idtoken-verifier used: 1.3.0
• Browser version tested: N/A (nodejs)
• Any other elevant environmental versions: Running in docker container for CI. Not seeing the issue on local machine.
• Additional modules/plugins/add-ons that might be affecting your instance:

Reproduction

Requiring this package will cause immediate error:

[05:30:37] ReferenceError: window is not defined
    at Object.<anonymous> (/builds/<project path>/node_modules/idtoken-verifier/build/idtoken-verifier.js:1:29120)
    at Module._compile (internal/modules/cjs/loader.js:689:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:700:10)
    at Module.load (internal/modules/cjs/loader.js:599:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:538:12)
    at Function.Module._load (internal/modules/cjs/loader.js:530:3)
    at Module.require (internal/modules/cjs/loader.js:637:17)
    at require (internal/modules/cjs/helpers.js:20:18)
    at Object.<anonymous> (/builds/<project path>/<file>.js)

It would be useful to support also elliptic curve algorithms like ES256 which some token providers use.

It is well-mentioned that jwksCache: the verifier will try to fetch the JWKS from the /.well-known/jwks.json endpoint each time it verifies a token. But this may not be always the case. This is the sitution for the company I am working on. Should such an assumption be so rigid? What about providing support for fetching the keys from other location? What about taking this param as a config param?

I tried to upgrade the library to latest version in a Nodejs express application and it now fails with ReferenceError 'XMLHttpRequest is not defined'. Is this possibly caused by changes in the library or should I modify my application code somehow?

Hi, I am trying to use this library for verifying the validity of jwt tokens on my node application. I was wondering why the description says "meant for the browser". Is there anything wrong in using this library server side for validating the tokens?
thanks :)

ReferenceError: XMLHttpRequest is not defined
at C:\projects\OI-Tracking\graphql\node_modules\idtoken-verifier\build\idtoken-verifier.js:1:34591
at new Promise ()
at S (C:\projects\OI-Tracking\graphql\node_modules\idtoken-verifier\build\idtoken-verifier.js:1:34559)
at C:\projects\OI-Tracking\graphql\node_modules\idtoken-verifier\build\idtoken-verifier.js:1:39970

Hi!

Would it be possible to include the TypeScript type definitions within the library to make the usage even easier?

BR,
Markus

Hello,
We use your component idtoken-verifier in our commercial product and therefore need to know the ECCN for it.

The ECCN is an international Export control and compliance number that is necessary for EVERY Export.
We need this information to classify our product embedding your component.
In case you have difficulties to provide us such ECCN number at least please answer the following questions, that will allow us to evaluate possible restriction on the exportability of the final product:

• Is the SW designed or modified to use cryptography performing any cryptographic function other than authentication or digital signature?
• If yes for what purpose is it used?
• Is your SW or part of it developed in US or by a US citizen?
• Is there US content in there? ( e.g. other open source libs)
• If yes what kind of SW?

Kind Regards,
Saurabh

Describe the problem you'd like to have solved

I am working with a service that returns JWT without a "sub" claim, and trying to validate it with this library throw an exception.

According to the RFC (section 4.1) all claims are optional, but this library expects (and requires) certain claims to be present: iss, sub, aud, nbf, iat

Describe the ideal solution

There should be a way to tell this library which claims to validate.

Alternatives and current work-arounds

There's no workaround besides forking this library (or using another one).

IdTokenVerifier throws TokenValidationError whenever the ID token fails to validate.

Currently it's not easy for the application to tell why the validation failed. Instead of parsing the error messages it should be possible to identify different errors by ID for example. This would let the application know whether given error is recoverable, so it may attempt to renew the session.

Environment

• Version of this library used: 2.0.0

Description

Angular 8 app running in latest chrome gives this console log when using target es2015 in tsconfig.json

AppComponent.html:8 ERROR TypeError: this.getTokenVerifier(...).decode is not a function

Reproduction

Run an angular 8 app using this module. Fail.
setting es5 in tsconfig.json makes it work.

Environment

version 1.4.1
angular 8
chrome 77.0.xxx