feat: added JWT validation logic @W-20036916@

[jfeingold35]

What does this PR do?

In addition to opaque tokens, certain APIs now accept JWT-style tokens. This adds the logic for validating the format of such a token.

What issues does this PR fix or reference?

@W-20036916@

[cristiand391]

QA notes:

setup:
yarn linked this branch into plugin-auth, then set SF_ACCESS_TOKEN to a real JWT issued from our devhub using my models connected app.

❌ allow sf org login access-token to support jwt tokens

still getting:

Error (SfError): The access token isn't in the correct format.
It should follow this pattern: "<org id>!<accesstoken>".

I figured it's due to the short-circuit of || here:

export const matchesAccessToken = (value: string): boolean =>
  matchesOpaqueAccessToken(value) || matchesJwtAccessToken(value);

so updated it to this to continue qa:

export const matchesAccessToken = (value: string): boolean => {
  if (matchesOpaqueAccessToken(value)) return true 
  if (matchesJwtAccessToken(value)) return true
  return false;
}

❌ matchesJwtAccessToken returns true for a valid jwt
while debugging it I noticed it failed while validating keys from the 2nd segment (index 1) in code:

return isJsonWithValidKeys(segments[1], ['aud', 'exp', 'iss', 'mty', 'nbf', 'sfi', 'sub', 'scp'], true, [
    'acx',
    'client_id',
    'iat',
    'roles',
    'obo',
  ]);

@jfeingold35 based on these docs I think we could simplify the key validation by just ensuring the typ field is JWT, ignoring all other keys:

• "typ" (Type) Header Parameter
• JWT-Based Access Tokens

I think we could omit checking for all other keys since we aren't validating their values, so typ seems enough to tell it's a jwt.

[cristiand391]

QA update:

❌ allow sf org login access-token to support jwt tokens

✅ fixed, can auth via an opaque token or jwt via SF_ACCESS_TOKEN or pasting the token in prompt (interactive mode)

❌ matchesJwtAccessToken returns true for a valid jwt

✅ fixed

❌ logger doesn't redact jwt

so if I do SF_ACCESS_TOKEN=<opaque-token> and do sf org login access-token ... --dev-debug, in logs I see the opaque token is always redacted:

but with SF_ACCESS_TOKEN=<jwt-based-access-token> I can see the non-encrypted token in logs

[cristiand391]

QA update:

❌ logger doesn't redact jwt

✅ jwt is partially redacted (limitation of how our logger works and jwt format)
Jamie pointed out I needed to link sfdx-core into the CLI too to get the env var section of the logs redacted,

code logging raw token:

which is logged as:

✅ also verified opaque tokens still get redacted