nodeSolidServer/oidc-op

Apparent confusion of `kty` and `alg`

michielbdejong opened this issue · 2 comments

The following DPoP token is not accepted by https://github.com/solid/identity-token-verifier:

{
  header: {
    alg: 'RS256',
    typ: 'dpop+jwt',
    jwk: {
      kty: 'RSA',
      kid: '3tjG2YeuINJZu1dsESrcDVLsH48wfPPJh_qvBX81Tcs',
      use: 'sig',
      alg: 'RSA',
      e: 'AQAB',
      n: '1JLhXFU_5eUoSXBg2QzuPL1zYgWY--3vEEgduukdODdieQXZOIWj2VKHxaHQzIgqQbZz8erx0DW6hGRbxKpkbVJbloK3zcVkPCooEctLDvTXARlpHihfAAh70IW2qK8jbaublaZ6WJg5pDLafLXwnMB6utg-MrdnFku_81WeDc93jCEs3UQOI80b_WpG1ZWnayy18cNKu-CyJIjwDjBpc7db5KTmkqkQdC-WKsHF4_-BM4nuX7zYQS6p1IUpjIBJDv2HkAaoanfP2xg42C3CBiFKHxBhYSytGgMRNX2Udj2ETDVCD0of2WCaRFqPQMuXtq_CWIFw6VflWDBq64iD_Q'
    }
  },
  payload: {
    htu: 'http://localhost:3000/.acl',
    htm: 'GET',
    jti: '4d7c8dd5-a899-4907-a551-36e1ba76a30b',
    iat: 1613376843,
    exp: 1613380443
  },
  signature: '0SKJZL17j4sjqIR6_4o4ocNUV3xq60gmbZpsVzjaHy0o67FlZ4P3q3yFuIS0-3MOts3RNp5I6YllBfti-b9A4aVUATOKJcNvwQercWw5vvMg3v252XjV8E86Ir3oDVAlqHTEYX89AjeZ73PN9gI0x8D3pP0mr1wcpZcvj7jM4u57XN3GTH4uYATQT1wdAhmz9y_sKSw_7K0zZOC8ItfDtfdr1FROn2UyWdVzLeI_pbKHLv7CyngoKbJPZrwqYQ9sKXSXw4m9IH6-71RPTHhCUxG1EyC6igytCi6QmuSYm1sBWin-tuuCGFFvLRn0A_yWxWwCc5Sq_xeH15bWXerzMA'
}

Note that both header.jwk.kty and header.jwk.alg have the value 'RSA'.
It makes community-server output a validation error which is thrown in https://github.com/solid/identity-token-verifier/blob/0cbb50406717496ecc900d1e3171b2f7ee946a31/src/guards/DPoPJWKGuard.ts#L65
It checks if RSA is in Set { 'RS256', 'RS384', 'RS512' }, which it is not.

And indeed, if you change header.jwk.alg to 'RS256', then community-server correctly logs:

Verified WebID via DPoP-bound access token: https://solid-crud-tests-example-1.solidcommunity.net/profile/card#me

The jwk.alg field is incorrect. If present, the value should be one of those listed by IANA: https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms

In this case, the alg field should be RS256

Turns out NSS behaviour was fine, and it was solid-auth-fetcher that was setting the wrong value!