Replies: 1 comment
-
| Hi Dave, 
 Thanks 
 Exactly what i'd expect. 
 We could, but IdP specific quirk and bug workarounds that add code surface on the account of someone not following IANA aren't something i consider for my libraries. | 
Beta Was this translation helpful? Give feedback.
                  
                    0 replies
                  
                
            
  
    Sign up for free
    to join this conversation on GitHub.
    Already have an account?
    Sign in to comment
  
        
    
Uh oh!
There was an error while loading. Please reload this page.
-
Hi,
This may be more of a problem w/ ADFS (and it usually is) but it was issuing an auth_time claim for access tokens as an ISO-8601 string instead of a UNIX timestamp:
{ "typ": "JWT", "alg": "RS256", "x5t": "..." }.{ "aud": "...", "iss": "...", "iat": 1584215370, "exp": 1584218970, "upn": "...", "apptype": "Confidential", "appid": "...", "authmethod": "urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport", "auth_time": "2020-03-14T18:52:01.180Z", "ver": "1.0", "scp": "openid" }.[Signature]This caused JWT.verify() to throw (rightly so) since auth_time wasn't in the expected format. You could do something like this in lib/jwt/verify.js to work around it:
Oddly enough, the ID tokens issued by ADFS don't have this problem. Anyway, this is a great lib and has been very helpful w/ validating JWT bearer tokens. Keep up the good work.
Thanks,
Dave Stelts
Beta Was this translation helpful? Give feedback.
All reactions