Typo in README.md[BUG]

Question

Typo in README.md[BUG]

johnhartman opened this issue 2 years ago · 8 comments

johnhartman commented 2 years ago

In the README.md file, line 309, 'customJwtChecks' should be 'customJwtCheck'.

ottokruse commented 2 years ago

Thanks!

Answer 1 · 2022-07-21T06:43:29.000Z

Thanks! Also ... great opportunity to become a contributor to the repo :)

Answer 2 · 2022-07-30T12:18:47.000Z

Thanks! Also ... great opportunity to become a contributor to the repo :)

A good one indeed :)

Answer 3 · 2022-08-18T18:40:03.000Z

Hey Otto— Quick question for you: for the multiple verifier, what order does the verification occur in? Serially in order of the array declaration? Parallel via Promise<result>? best, John 510.206.5846 (mobile)

…

On Wed, Jul 20, 2022 at 11:43 PM Otto Kruse ***@***.***> wrote: Thanks! Also ... great opportunity to become a contributor to the repo :) — Reply to this email directly, view it on GitHub <#78 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACAFWPXM276DKZFYLAKSI3TVVDWRXANCNFSM5364SNSQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

Answer 4 · 2022-08-19T06:39:22.000Z

Hi John. The JWT is just verified once actually. The array you pass in, is turned into a hash map of issuer configurations, where issuer is the key. During verification, using the issuer (iss) from the JWT payload, the right config is loaded from the hash map.

Answer 5 · 2022-08-20T22:08:36.000Z

Thanks for the quick response. Was actually wondering about the order that the tokens are decoded, or are they decoded in parallel? Here's the deal: I'm on a project replacing a well-known identity provider with Cognito. New API calls will handle the old provider's tokens if the tokens fail to decode via cognito. Therefore I'd like to decode via cognito first, then fall back to the old provider. Does the decode occur serially in the order of the provider array, or in parallel via promises? best, John 510.206.5846 (mobile)

…

On Thu, Aug 18, 2022 at 11:39 PM Otto Kruse ***@***.***> wrote: Hi John. The JWT is just verified once actually. The array you pass in, is turned into a hash map of issuer configurations, where issuer is the key. During verification, using the issuer (iss) from the JWT payload, the right config is loaded from the hash map. — Reply to this email directly, view it on GitHub <#78 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACAFWPSAFKRPHEJDKJJNLGLVZ4T2JANCNFSM5364SNSQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

Answer 6 · 2022-08-22T06:52:05.000Z

Hi John, if you use the multi-verifier from this library, your JWT will be decoded and verified once.

The lib will look at your JWT's iss claim. Cognito will put a different iss in the JWTs than your old provider. So by looking at the iss claim the library will know which one of the issuer configurations (that you provided as an array) to use.

Does that make sense?

Answer 7 · 2022-10-11T08:47:04.000Z

TL;DR: ignorant me :) Didn't realize that parts 0 and 1 are not encrypted, just base64'ed. So was thinking decrypting was required to determine who issued the token. All is good now. Thank you for helping me. best, John 510.206.5846 (mobile)

…

On Sun, Aug 21, 2022 at 11:52 PM Otto Kruse ***@***.***> wrote: Hi John, if you use the multi-verifier from this library, your JWT will be decoded and verified once. The lib will look at your JWT's iss claim. Cognito will put a different iss in the JWTs than your old provider. So by looking at the kid claim the library will know which *one* of the issuer configurations (that you provided as an array) to use. Does that make sense? — Reply to this email directly, view it on GitHub <#78 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACAFWPWJKVGMZV4HAQS3SRDV2MPSHANCNFSM5364SNSQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>