Giter Club home page Giter Club logo

Comments (10)

aj-michael avatar aj-michael commented on May 17, 2024 1

adding to this, using a keyfinder block is really ugly if you have additionaly options to pass in.

JWT.decode(raw_token, nil, true, additional_options) do |header|
  ...
end

I don't like that I have to pass in a key (nil) that is going to be ignored anyways. Especially since I have to pass in an options has to do full validation in accordance with the RFC. I'm also not a fan of raw booleans, because someone reading my code in the future has no easy way to know what the true refers to.

from ruby-jwt.

excpt avatar excpt commented on May 17, 2024 1

@itstehkman I would go for the JWS RFC 7515 specs. This should keep things as simple and should avoid the redundancy.

from ruby-jwt.

excpt avatar excpt commented on May 17, 2024

We need to implement JWK for that. You may have a look at the 2.x branch.

from ruby-jwt.

stunney avatar stunney commented on May 17, 2024

Don't forget, you need the ENTIRE certificate chain in that field. The signing certificate first followed by each intermediate and root CA that owns that one.

from ruby-jwt.

punkle avatar punkle commented on May 17, 2024

@stunney It 'MAY' contain the entire certificate chain. The last certificate in the x5c chain could be rooted in a certificate store managed by the entity validating the token.

from ruby-jwt.

stunney avatar stunney commented on May 17, 2024

You are correct. The first must be the cert that signed the token. The rest are optional.

from ruby-jwt.

itstehkman avatar itstehkman commented on May 17, 2024

Hey @punkle @excpt, I'm taking a quick stab at this since I need support for this. Open question:

Should this be implementing x5c as specified in JWS (RFC-7515) or as specified in JWK?

JWS spec for x5c:

The "x5c" (X.509 certificate chain) Header Parameter contains the
   X.509 public key certificate or certificate chain [RFC5280]
   corresponding to the key used to digitally sign the JWS.  The
   certificate or certificate chain is represented as a JSON array of
   certificate value strings.  Each string in the array is a
   base64-encoded (Section 4 of [RFC4648] -- not base64url-encoded) DER
   [ITU.X690.2008] PKIX certificate value.  The certificate containing
   the public key corresponding to the key used to digitally sign the
   JWS MUST be the first certificate.  This MAY be followed by
   additional certificates, with each subsequent certificate being the
   one used to certify the previous one.  The recipient MUST validate
   the certificate chain according to RFC 5280 [RFC5280] and consider
   the certificate or certificate chain to be invalid if any validation
   failure occurs.  Use of this Header Parameter is OPTIONAL.

JWK spec for x5c:

The "x5c" (X.509 certificate chain) parameter contains a chain of one
   or more PKIX certificates [RFC5280].  The certificate chain is
   represented as a JSON array of certificate value strings.  Each
   string in the array is a base64-encoded (Section 4 of [RFC4648] --
   not base64url-encoded) DER [ITU.X690.1994] PKIX certificate value.
   The PKIX certificate containing the key value MUST be the first
   certificate.  This MAY be followed by additional certificates, with
   each subsequent certificate being the one used to certify the
   previous one.  The key in the first certificate MUST match the public
   key represented by other members of the JWK.  Use of this member is
   OPTIONAL.

   As with the "x5u" member, optional JWK members providing key usage,
   algorithm, or other information MAY also be present when the "x5c"
   member is used.  If other members are present, the contents of those
   members MUST be semantically consistent with the related fields in
   the first certificate.  See the last paragraph of Section 4.6 for
   additional guidance on this.

the main difference being that the JWK spec also wants you to supply the public key in one of the JWK fields, which feels redundant to me since it is already in the x5c field's first cert.

from ruby-jwt.

itstehkman avatar itstehkman commented on May 17, 2024

Ping @punkle @excpt

from ruby-jwt.

punkle avatar punkle commented on May 17, 2024

@itstehkman I am not very familiar with the specs. Can both be supported?

from ruby-jwt.

itstehkman avatar itstehkman commented on May 17, 2024

Sounds good! After taking a look at most common implementations, they use the JWK RFC. I can probably do this in two parts - first part supporting the JWK implementation, then the pure JWS implementation too.

from ruby-jwt.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.