0

I'm essentially doing something very similar to this post. I would like to be able to verify some JWT tokens that have been signed on an IdentityServer, and there are a few details that I haven't figured out yet. Here is an example token:

eyJhbGciOiJSUzI1NiIsImtpZCI6IjBiZjM5OWIwYjRkNzY3OTE5MDFlYzlmNTUxNTZkMzdlIiwidHlwIjoiSldUIn0.eyJuYmYiOjE1Mjc4OTA2MDAsImV4cCI6MTUyNzg5NDIwMCwiaXNzIjoiaHR0cDovL2NvbW1hbmRjZW50ZXI6NTAwMCIsImF1ZCI6Imh0dHA6Ly9jb21tYW5kY2VudGVyOjUwMDAvcmVzb3VyY2VzIiwiY2xpZW50X2lkIjoiY29tbWFuZGNlbnRlciIsInN1YiI6ImU3NzY4MjEyLTdhMGYtNDA4YS04YzlmLWZmNDRmOTVlNzc2ZSIsImF1dGhfdGltZSI6MTUyNzg5MDYwMCwiaWRwIjoibG9jYWwiLCJzY29wZSI6WyJvcGVuaWQiLCJwcm9maWxlIl0sImFtciI6WyJwd2QiXX0.N6j_8Mbc-WAZInLnhauBS_dC6my3ggJEFGNBuuanJXGG5Q1mL7K9KZ11cgxrWQEp6NRS07bZrh02qA0Hcd0pLJzg0xB49CR-kFlA8PWdZ-wnf1U4VGq7ZZY2PaxccqextF-s3V-ObEsnPq7k1csTBM_lBW5u4m907q3zcHfPtW9RNz3kELKSuW1vMOWksrOOaJO3UGAPJgRcFjlc5imPykKQVCiAO9UV1nuNUHOLOu4XDim-f3YHLU24J-vbgxkqdUtgs4Xm43b3AplYrkN_TJ0ba5demtnQNd5No0s6bkqkuPvVGz2G3MD5tWkQVnu7kV7GNfTOvJlInCkDOE6few

Taking this over to https://jwt.io/ you can see that the token parses out to be 

{
  "alg": "RS256",
  "kid": "0bf399b0b4d76791901ec9f55156d37e",
  "typ": "JWT"
}.
{
  "nbf": 1527890600,
  "exp": 1527894200,
  "iss": "http://commandcenter:5000",
  "aud": "http://commandcenter:5000/resources",
  "client_id": "commandcenter",
  "sub": "e7768212-7a0f-408a-8c9f-ff44f95e776e",
  "auth_time": 1527890600,
  "idp": "local",
  "scope": [
    "openid",
    "profile"
  ],
  "amr": [
    "pwd"
  ]
}.
{SIGNATURE}

I've seen 2 main ways in which tokens are signed. One is just using some passpharase that everyone magically has to know in order to verify the token. We don't want to have to manage updating multiple clients when a passphrase changes, so this is not an option for us. The other way is to use essentially a PKI method much like how HTTPS keys are exchanged and authenticated using X509 certificates. I have a few questions about this and this particular example:

1. Why isn't the 3rd and final section of the token Base64 encoded? I'm guessing its Base64Url, is that right? The rest of the segments use Base64, why not this one as well?

2. We would like to use essentially SSL certificates for signing and I presume this example token has done the same, but how does the receiver know which public certificate it should fetch in order to validate this token? Shouldn't the certificate serial number be provided?

3. Why is this signature so big? This seems like way to many bytes for just a signature, is there other data packed inside?

Ultratrunks
  • 2,464
  • 5
  • 28
  • 48
  • 1
    1. according to RFC7515: [In both serializations, the JWS Protected Header, JWS Payload, and JWS Signature are base64url encoded](https://tools.ietf.org/html/rfc7515#section-3) – jps Jun 04 '18 at 21:38
  • Oh yah, I see. I was using a regular base64 decoder/encoder with the first 2 sections and wasn't having any issues so I assumed the last guy was the odd man out. Thank you. – Ultratrunks Jun 04 '18 at 22:34
  • 2: The public certificate is available through /.well-known/openid-configuration/jwks – Espen Medbø Jun 07 '18 at 05:09

0 Answers0