Giter Club home page Giter Club logo

ruby-jwt's Introduction

JWT

Gem Version Build Status Code Climate Test Coverage Issue Count

A ruby implementation of the RFC 7519 OAuth JSON Web Token (JWT) standard.

If you have further questions related to development or usage, join us: ruby-jwt google group.

Announcements

  • Ruby 2.4 support was dropped in version 2.4.0
  • Ruby 1.9.3 support was dropped at December 31st, 2016.
  • Version 1.5.3 yanked. See: #132 and #133

See CHANGELOG.md for a complete set of changes.

Sponsors

Logo Message
auth0 logo If you want to quickly add secure token-based authentication to Ruby projects, feel free to check Auth0's Ruby SDK and free plan at auth0.com/developers

Installing

Using Rubygems:

gem install jwt

Using Bundler:

Add the following to your Gemfile

gem 'jwt'

And run bundle install

Algorithms and Usage

The JWT spec supports NONE, HMAC, RSASSA, ECDSA and RSASSA-PSS algorithms for cryptographic signing. Currently the jwt gem supports NONE, HMAC, RSASSA and ECDSA. If you are using cryptographic signing, you need to specify the algorithm in the options hash whenever you call JWT.decode to ensure that an attacker cannot bypass the algorithm verification step. It is strongly recommended that you hard code the algorithm, as you may leave yourself vulnerable by dynamically picking the algorithm

See: JSON Web Algorithms (JWA) 3.1. "alg" (Algorithm) Header Parameter Values for JWS

Deprecation warnings

Deprecation warnings are logged once (:once option) by default to avoid spam in logs. Other options are :silent to completely silence warnings and :warn to log every time a deprecated path is executed.

  JWT.configuration.deprecation_warnings = :warn # default is :once

Base64 decoding

In the past the gem has been supporting the Base64 decoding specified in RFC2045 allowing newlines and blanks in the base64 encoded payload. In future versions base64 decoding will be stricter and only comply to RFC4648.

The stricter base64 decoding when processing tokens can be done via the strict_base64_decoding configuration accessor.

  JWT.configuration.strict_base64_decoding = true # default is false

NONE

  • none - unsigned token
require 'jwt'

payload = { data: 'test' }

# IMPORTANT: set nil as password parameter
token = JWT.encode payload, nil, 'none'

# eyJhbGciOiJub25lIn0.eyJkYXRhIjoidGVzdCJ9.
puts token

# Set password to nil and validation to false otherwise this won't work
decoded_token = JWT.decode token, nil, false

# Array
# [
#   {"data"=>"test"}, # payload
#   {"alg"=>"none"} # header
# ]
puts decoded_token

HMAC

  • HS256 - HMAC using SHA-256 hash algorithm
  • HS384 - HMAC using SHA-384 hash algorithm
  • HS512 - HMAC using SHA-512 hash algorithm
# The secret must be a string. With OpenSSL 3.0/openssl gem `<3.0.1`, JWT::DecodeError will be raised if it isn't provided.
hmac_secret = 'my$ecretK3y'

token = JWT.encode payload, hmac_secret, 'HS256'

# eyJhbGciOiJIUzI1NiJ9.eyJkYXRhIjoidGVzdCJ9.pNIWIL34Jo13LViZAJACzK6Yf0qnvT_BuwOxiMCPE-Y
puts token

decoded_token = JWT.decode token, hmac_secret, true, { algorithm: 'HS256' }

# Array
# [
#   {"data"=>"test"}, # payload
#   {"alg"=>"HS256"} # header
# ]
puts decoded_token

RSA

  • RS256 - RSA using SHA-256 hash algorithm
  • RS384 - RSA using SHA-384 hash algorithm
  • RS512 - RSA using SHA-512 hash algorithm
rsa_private = OpenSSL::PKey::RSA.generate 2048
rsa_public = rsa_private.public_key

token = JWT.encode payload, rsa_private, 'RS256'

# eyJhbGciOiJSUzI1NiJ9.eyJkYXRhIjoidGVzdCJ9.GplO4w1spRgvEJQ3-FOtZr-uC8L45Jt7SN0J4woBnEXG_OZBSNcZjAJWpjadVYEe2ev3oUBFDYM1N_-0BTVeFGGYvMewu8E6aMjSZvOpf1cZBew-Vt4poSq7goG2YRI_zNPt3af2lkPqXD796IKC5URrEvcgF5xFQ-6h07XRDpSRx1ECrNsUOt7UM3l1IB4doY11GzwQA5sHDTmUZ0-kBT76ZMf12Srg_N3hZwphxBtudYtN5VGZn420sVrQMdPE_7Ni3EiWT88j7WCr1xrF60l8sZT3yKCVleG7D2BEXacTntB7GktBv4Xo8OKnpwpqTpIlC05dMowMkz3rEAAYbQ
puts token

decoded_token = JWT.decode token, rsa_public, true, { algorithm: 'RS256' }

# Array
# [
#   {"data"=>"test"}, # payload
#   {"alg"=>"RS256"} # header
# ]
puts decoded_token

ECDSA

  • ES256 - ECDSA using P-256 and SHA-256
  • ES384 - ECDSA using P-384 and SHA-384
  • ES512 - ECDSA using P-521 and SHA-512
  • ES256K - ECDSA using P-256K and SHA-256
ecdsa_key = OpenSSL::PKey::EC.generate('prime256v1')

token = JWT.encode payload, ecdsa_key, 'ES256'

# eyJhbGciOiJFUzI1NiJ9.eyJkYXRhIjoidGVzdCJ9.AlLW--kaF7EX1NMX9WJRuIW8NeRJbn2BLXHns7Q5TZr7Hy3lF6MOpMlp7GoxBFRLISQ6KrD0CJOrR8aogEsPeg
puts token

decoded_token = JWT.decode token, ecdsa_key, true, { algorithm: 'ES256' }

# Array
# [
#    {"test"=>"data"}, # payload
#    {"alg"=>"ES256"} # header
# ]
puts decoded_token

EDDSA

In order to use this algorithm you need to add the RbNaCl gem to you Gemfile.

gem 'rbnacl'

For more detailed installation instruction check the official repository on GitHub.

  • ED25519
private_key = RbNaCl::Signatures::Ed25519::SigningKey.new('abcdefghijklmnopqrstuvwxyzABCDEF')
public_key = private_key.verify_key
token = JWT.encode payload, private_key, 'ED25519'

# eyJhbGciOiJFRDI1NTE5In0.eyJkYXRhIjoidGVzdCJ9.6xIztXyOupskddGA_RvKU76V9b2dCQUYhoZEVFnRimJoPYIzZ2Fm47CWw8k2NTCNpgfAuxg9OXjaiVK7MvrbCQ
puts token

decoded_token = JWT.decode token, public_key, true, { algorithm: 'ED25519' }
# Array
# [
#  {"test"=>"data"}, # payload
#  {"alg"=>"ED25519"} # header
# ]

RSASSA-PSS

In order to use this algorithm you need to add the openssl gem to your Gemfile with a version greater or equal to 2.1.

gem 'openssl', '~> 2.1'
  • PS256 - RSASSA-PSS using SHA-256 hash algorithm
  • PS384 - RSASSA-PSS using SHA-384 hash algorithm
  • PS512 - RSASSA-PSS using SHA-512 hash algorithm
rsa_private = OpenSSL::PKey::RSA.generate 2048
rsa_public = rsa_private.public_key

token = JWT.encode payload, rsa_private, 'PS256'

# eyJhbGciOiJQUzI1NiJ9.eyJkYXRhIjoidGVzdCJ9.KEmqagMUHM-NcmXo6818ZazVTIAkn9qU9KQFT1c5Iq91n0KRpAI84jj4ZCdkysDlWokFs3Dmn4MhcXP03oJKLFgnoPL40_Wgg9iFr0jnIVvnMUp1kp2RFUbL0jqExGTRA3LdAhuvw6ZByGD1bkcWjDXygjQw-hxILrT1bENjdr0JhFd-cB0-ps5SB0mwhFNcUw-OM3Uu30B1-mlFaelUY8jHJYKwLTZPNxHzndt8RGXF8iZLp7dGb06HSCKMcVzhASGMH4ZdFystRe2hh31cwcvnl-Eo_D4cdwmpN3Abhk_8rkxawQJR3duh8HNKc4AyFPo7SabEaSu2gLnLfN3yfg
puts token

decoded_token = JWT.decode token, rsa_public, true, { algorithm: 'PS256' }

# Array
# [
#   {"data"=>"test"}, # payload
#   {"alg"=>"PS256"} # header
# ]
puts decoded_token

Custom algorithms

An object implementing custom signing or verification behaviour can be passed in the algorithm option when encoding and decoding. The given object needs to implement the method valid_alg? and verify and/or alg and sign, depending if object is used for encoding or decoding.

module CustomHS512Algorithm
  def self.alg
    'HS512'
  end

  def self.valid_alg?(alg_to_validate)
    alg_to_validate == alg
  end

  def self.sign(data:, signing_key:)
    OpenSSL::HMAC.digest(OpenSSL::Digest.new('sha512'), data, signing_key)
  end

  def self.verify(data:, signature:, verification_key:)
    ::OpenSSL.secure_compare(sign(data: data, signing_key: verification_key), signature)
  end
end

token = ::JWT.encode({'pay' => 'load'}, 'secret', CustomHS512Algorithm)
payload, header = ::JWT.decode(token, 'secret', true, algorithm: CustomHS512Algorithm)

Support for reserved claim names

JSON Web Token defines some reserved claim names and defines how they should be used. JWT supports these reserved claim names:

  • 'exp' (Expiration Time) Claim
  • 'nbf' (Not Before Time) Claim
  • 'iss' (Issuer) Claim
  • 'aud' (Audience) Claim
  • 'jti' (JWT ID) Claim
  • 'iat' (Issued At) Claim
  • 'sub' (Subject) Claim

Add custom header fields

Ruby-jwt gem supports custom header fields To add custom header fields you need to pass header_fields parameter

token = JWT.encode payload, key, algorithm='HS256', header_fields={}

Example:

require 'jwt'

payload = { data: 'test' }

# IMPORTANT: set nil as password parameter
token = JWT.encode payload, nil, 'none', { typ: 'JWT' }

# eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJkYXRhIjoidGVzdCJ9.
puts token

# Set password to nil and validation to false otherwise this won't work
decoded_token = JWT.decode token, nil, false

# Array
# [
#   {"data"=>"test"}, # payload
#   {"typ"=>"JWT", "alg"=>"none"} # header
# ]
puts decoded_token

Expiration Time Claim

From Oauth JSON Web Token 4.1.4. "exp" (Expiration Time) Claim:

The exp (expiration time) claim identifies the expiration time on or after which the JWT MUST NOT be accepted for processing. The processing of the exp claim requires that the current date/time MUST be before the expiration date/time listed in the exp claim. Implementers MAY provide for some small leeway, usually no more than a few minutes, to account for clock skew. Its value MUST be a number containing a NumericDate value. Use of this claim is OPTIONAL.

Handle Expiration Claim

exp = Time.now.to_i + 4 * 3600
exp_payload = { data: 'data', exp: exp }

token = JWT.encode exp_payload, hmac_secret, 'HS256'

begin
  decoded_token = JWT.decode token, hmac_secret, true, { algorithm: 'HS256' }
rescue JWT::ExpiredSignature
  # Handle expired token, e.g. logout user or deny access
end

The Expiration Claim verification can be disabled.

# Decode token without raising JWT::ExpiredSignature error
JWT.decode token, hmac_secret, true, { verify_expiration: false, algorithm: 'HS256' }

Adding Leeway

exp = Time.now.to_i - 10
leeway = 30 # seconds

exp_payload = { data: 'data', exp: exp }

# build expired token
token = JWT.encode exp_payload, hmac_secret, 'HS256'

begin
  # add leeway to ensure the token is still accepted
  decoded_token = JWT.decode token, hmac_secret, true, { exp_leeway: leeway, algorithm: 'HS256' }
rescue JWT::ExpiredSignature
  # Handle expired token, e.g. logout user or deny access
end

Not Before Time Claim

From Oauth JSON Web Token 4.1.5. "nbf" (Not Before) Claim:

The nbf (not before) claim identifies the time before which the JWT MUST NOT be accepted for processing. The processing of the nbf claim requires that the current date/time MUST be after or equal to the not-before date/time listed in the nbf claim. Implementers MAY provide for some small leeway, usually no more than a few minutes, to account for clock skew. Its value MUST be a number containing a NumericDate value. Use of this claim is OPTIONAL.

Handle Not Before Claim

nbf = Time.now.to_i - 3600
nbf_payload = { data: 'data', nbf: nbf }

token = JWT.encode nbf_payload, hmac_secret, 'HS256'

begin
  decoded_token = JWT.decode token, hmac_secret, true, { algorithm: 'HS256' }
rescue JWT::ImmatureSignature
  # Handle invalid token, e.g. logout user or deny access
end

The Not Before Claim verification can be disabled.

# Decode token without raising JWT::ImmatureSignature error
JWT.decode token, hmac_secret, true, { verify_not_before: false, algorithm: 'HS256' }

Adding Leeway

nbf = Time.now.to_i + 10
leeway = 30

nbf_payload = { data: 'data', nbf: nbf }

# build expired token
token = JWT.encode nbf_payload, hmac_secret, 'HS256'

begin
  # add leeway to ensure the token is valid
  decoded_token = JWT.decode token, hmac_secret, true, { nbf_leeway: leeway, algorithm: 'HS256' }
rescue JWT::ImmatureSignature
  # Handle invalid token, e.g. logout user or deny access
end

Issuer Claim

From Oauth JSON Web Token 4.1.1. "iss" (Issuer) Claim:

The iss (issuer) claim identifies the principal that issued the JWT. The processing of this claim is generally application specific. The iss value is a case-sensitive string containing a StringOrURI value. Use of this claim is OPTIONAL.

You can pass multiple allowed issuers as an Array, verification will pass if one of them matches the iss value in the payload.

iss = 'My Awesome Company Inc. or https://my.awesome.website/'
iss_payload = { data: 'data', iss: iss }

token = JWT.encode iss_payload, hmac_secret, 'HS256'

begin
  # Add iss to the validation to check if the token has been manipulated
  decoded_token = JWT.decode token, hmac_secret, true, { iss: iss, verify_iss: true, algorithm: 'HS256' }
rescue JWT::InvalidIssuerError
  # Handle invalid token, e.g. logout user or deny access
end

You can also pass a Regexp or Proc (with arity 1), verification will pass if the regexp matches or the proc returns truthy. On supported ruby versions (>= 2.5) you can also delegate to methods, on older versions you will have to convert them to proc (using to_proc)

JWT.decode token, hmac_secret, true,
           iss: %r'https://my.awesome.website/',
           verify_iss: true,
           algorithm: 'HS256'
JWT.decode token, hmac_secret, true,
           iss: ->(issuer) { issuer.start_with?('My Awesome Company Inc') },
           verify_iss: true,
           algorithm: 'HS256'
JWT.decode token, hmac_secret, true,
           iss: method(:valid_issuer?),
           verify_iss: true,
           algorithm: 'HS256'

# somewhere in the same class:
def valid_issuer?(issuer)
  # custom validation
end

Audience Claim

From Oauth JSON Web Token 4.1.3. "aud" (Audience) Claim:

The aud (audience) claim identifies the recipients that the JWT is intended for. Each principal intended to process the JWT MUST identify itself with a value in the audience claim. If the principal processing the claim does not identify itself with a value in the aud claim when this claim is present, then the JWT MUST be rejected. In the general case, the aud value is an array of case-sensitive strings, each containing a StringOrURI value. In the special case when the JWT has one audience, the aud value MAY be a single case-sensitive string containing a StringOrURI value. The interpretation of audience values is generally application specific. Use of this claim is OPTIONAL.

aud = ['Young', 'Old']
aud_payload = { data: 'data', aud: aud }

token = JWT.encode aud_payload, hmac_secret, 'HS256'

begin
  # Add aud to the validation to check if the token has been manipulated
  decoded_token = JWT.decode token, hmac_secret, true, { aud: aud, verify_aud: true, algorithm: 'HS256' }
rescue JWT::InvalidAudError
  # Handle invalid token, e.g. logout user or deny access
  puts 'Audience Error'
end

JWT ID Claim

From Oauth JSON Web Token 4.1.7. "jti" (JWT ID) Claim:

The jti (JWT ID) claim provides a unique identifier for the JWT. The identifier value MUST be assigned in a manner that ensures that there is a negligible probability that the same value will be accidentally assigned to a different data object; if the application uses multiple issuers, collisions MUST be prevented among values produced by different issuers as well. The jti claim can be used to prevent the JWT from being replayed. The jti value is a case-sensitive string. Use of this claim is OPTIONAL.

# Use the secret and iat to create a unique key per request to prevent replay attacks
jti_raw = [hmac_secret, iat].join(':').to_s
jti = Digest::MD5.hexdigest(jti_raw)
jti_payload = { data: 'data', iat: iat, jti: jti }

token = JWT.encode jti_payload, hmac_secret, 'HS256'

begin
  # If :verify_jti is true, validation will pass if a JTI is present
  #decoded_token = JWT.decode token, hmac_secret, true, { verify_jti: true, algorithm: 'HS256' }
  # Alternatively, pass a proc with your own code to check if the JTI has already been used
  decoded_token = JWT.decode token, hmac_secret, true, { verify_jti: proc { |jti| my_validation_method(jti) }, algorithm: 'HS256' }
  # or
  decoded_token = JWT.decode token, hmac_secret, true, { verify_jti: proc { |jti, payload| my_validation_method(jti, payload) }, algorithm: 'HS256' }
rescue JWT::InvalidJtiError
  # Handle invalid token, e.g. logout user or deny access
  puts 'Error'
end

Issued At Claim

From Oauth JSON Web Token 4.1.6. "iat" (Issued At) Claim:

The iat (issued at) claim identifies the time at which the JWT was issued. This claim can be used to determine the age of the JWT. The leeway option is not taken into account when verifying this claim. The iat_leeway option was removed in version 2.2.0. Its value MUST be a number containing a NumericDate value. Use of this claim is OPTIONAL.

Handle Issued At Claim

iat = Time.now.to_i
iat_payload = { data: 'data', iat: iat }

token = JWT.encode iat_payload, hmac_secret, 'HS256'

begin
  # Add iat to the validation to check if the token has been manipulated
  decoded_token = JWT.decode token, hmac_secret, true, { verify_iat: true, algorithm: 'HS256' }
rescue JWT::InvalidIatError
  # Handle invalid token, e.g. logout user or deny access
end

Subject Claim

From Oauth JSON Web Token 4.1.2. "sub" (Subject) Claim:

The sub (subject) claim identifies the principal that is the subject of the JWT. The Claims in a JWT are normally statements about the subject. The subject value MUST either be scoped to be locally unique in the context of the issuer or be globally unique. The processing of this claim is generally application specific. The sub value is a case-sensitive string containing a StringOrURI value. Use of this claim is OPTIONAL.

sub = 'Subject'
sub_payload = { data: 'data', sub: sub }

token = JWT.encode sub_payload, hmac_secret, 'HS256'

begin
  # Add sub to the validation to check if the token has been manipulated
  decoded_token = JWT.decode token, hmac_secret, true, { sub: sub, verify_sub: true, algorithm: 'HS256' }
rescue JWT::InvalidSubError
  # Handle invalid token, e.g. logout user or deny access
end

Finding a Key

To dynamically find the key for verifying the JWT signature, pass a block to the decode block. The block receives headers and the original payload as parameters. It should return with the key to verify the signature that was used to sign the JWT.

issuers = %w[My_Awesome_Company1 My_Awesome_Company2]
iss_payload = { data: 'data', iss: issuers.first }

secrets = { issuers.first => hmac_secret, issuers.last => 'hmac_secret2' }

token = JWT.encode iss_payload, hmac_secret, 'HS256'

begin
  # Add iss to the validation to check if the token has been manipulated
  decoded_token = JWT.decode(token, nil, true, { iss: issuers, verify_iss: true, algorithm: 'HS256' }) do |_headers, payload|
    secrets[payload['iss']]
  end
rescue JWT::InvalidIssuerError
  # Handle invalid token, e.g. logout user or deny access
end

Required Claims

You can specify claims that must be present for decoding to be successful. JWT::MissingRequiredClaim will be raised if any are missing

# Will raise a JWT::MissingRequiredClaim error if the 'exp' claim is absent
JWT.decode token, hmac_secret, true, { required_claims: ['exp'], algorithm: 'HS256' }

X.509 certificates in x5c header

A JWT signature can be verified using certificate(s) given in the x5c header. Before doing that, the trustworthiness of these certificate(s) must be established. This is done in accordance with RFC 5280 which (among other things) verifies the certificate(s) are issued by a trusted root certificate, the timestamps are valid, and none of the certificate(s) are revoked (i.e. being present in the root certificate's Certificate Revocation List).

root_certificates = [] # trusted `OpenSSL::X509::Certificate` objects
crl_uris = root_certificates.map(&:crl_uris)
crls = crl_uris.map do |uri|
  # look up cached CRL by `uri` and return it if found, otherwise continue
  crl = Net::HTTP.get(uri)
  crl = OpenSSL::X509::CRL.new(crl)
  # cache `crl` using `uri` as the key, expiry set to `crl.next_update` timestamp
end

begin
  JWT.decode(token, nil, true, { x5c: { root_certificates: root_certificates, crls: crls } })
rescue JWT::DecodeError
  # Handle error, e.g. x5c header certificate revoked or expired
end

JSON Web Key (JWK)

JWK is a JSON structure representing a cryptographic key. This gem currently supports RSA, EC, OKP and HMAC keys. OKP support requires RbNaCl and currently only supports the Ed25519 curve.

To encode a JWT using your JWK:

optional_parameters = { kid: 'my-kid', use: 'sig', alg: 'RS512' }
jwk = JWT::JWK.new(OpenSSL::PKey::RSA.new(2048), optional_parameters)

# Encoding
payload = { data: 'data' }
token = JWT.encode(payload, jwk.signing_key, jwk[:alg], kid: jwk[:kid])

# JSON Web Key Set for advertising your signing keys
jwks_hash = JWT::JWK::Set.new(jwk).export

To decode a JWT using a trusted entity's JSON Web Key Set (JWKS):

jwks = JWT::JWK::Set.new(jwks_hash)
jwks.filter! {|key| key[:use] == 'sig' } # Signing keys only!
algorithms = jwks.map { |key| key[:alg] }.compact.uniq
JWT.decode(token, nil, true, algorithms: algorithms, jwks: jwks)

The jwks option can also be given as a lambda that evaluates every time a kid is resolved. This can be used to implement caching of remotely fetched JWK Sets.

If the requested kid is not found from the given set the loader will be called a second time with the kid_not_found option set to true. The application can choose to implement some kind of JWK cache invalidation or other mechanism to handle such cases.

Tokens without a specified kid are rejected by default. This behaviour may be overwritten by setting the allow_nil_kid option for decode to true.

jwks_loader = ->(options) do
  # The jwk loader would fetch the set of JWKs from a trusted source.
  # To avoid malicious requests triggering cache invalidations there needs to be
  # some kind of grace time or other logic for determining the validity of the invalidation.
  # This example only allows cache invalidations every 5 minutes.
  if options[:kid_not_found] && @cache_last_update < Time.now.to_i - 300
    logger.info("Invalidating JWK cache. #{options[:kid]} not found from previous cache")
    @cached_keys = nil
  end
  @cached_keys ||= begin
    @cache_last_update = Time.now.to_i
    # Replace with your own JWKS fetching routine
    jwks = JWT::JWK::Set.new(jwks_hash)
    jwks.select! { |key| key[:use] == 'sig' } # Signing Keys only
    jwks
  end
end

begin
  JWT.decode(token, nil, true, { algorithms: ['RS512'], jwks: jwks_loader })
rescue JWT::JWKError
  # Handle problems with the provided JWKs
rescue JWT::DecodeError
  # Handle other decode related issues e.g. no kid in header, no matching public key found etc.
end

Importing and exporting JSON Web Keys

The ::JWT::JWK class can be used to import both JSON Web Keys and OpenSSL keys and export to either format with and without the private key included.

To include the private key in the export pass the include_private parameter to the export method.

# Import a JWK Hash (showing an HMAC example)
jwk = JWT::JWK.new({ kty: 'oct', k: 'my-secret', kid: 'my-kid' })

# Import an OpenSSL key
# You can optionally add descriptive parameters to the JWK
desc_params = { kid: 'my-kid', use: 'sig' }
jwk = JWT::JWK.new(OpenSSL::PKey::RSA.new(2048), desc_params)

# Export as JWK Hash (public key only by default)
jwk_hash = jwk.export
jwk_hash_with_private_key = jwk.export(include_private: true)

# Export as OpenSSL key
public_key = jwk.verify_key
private_key = jwk.signing_key if jwk.private?

# You can also import and export entire JSON Web Key Sets
jwks_hash = { keys: [{ kty: 'oct', k: 'my-secret', kid: 'my-kid' }] }
jwks = JWT::JWK::Set.new(jwks_hash)
jwks_hash = jwks.export

Key ID (kid) and JWKs

The key id (kid) generation in the gem is a custom algorithm and not based on any standards. To use a standardized JWK thumbprint (RFC 7638) as the kid for JWKs a generator type can be specified in the global configuration or can be given to the JWK instance on initialization.

JWT.configuration.jwk.kid_generator_type = :rfc7638_thumbprint
# OR
JWT.configuration.jwk.kid_generator = ::JWT::JWK::Thumbprint
# OR
jwk = JWT::JWK.new(OpenSSL::PKey::RSA.new(2048), nil, kid_generator: ::JWT::JWK::Thumbprint)

jwk_hash = jwk.export

thumbprint_as_the_kid = jwk_hash[:kid]

Development and Tests

We depend on Bundler for defining gemspec and performing releases to rubygems.org, which can be done with

rake release

The tests are written with rspec. Appraisal is used to ensure compatibility with 3rd party dependencies providing cryptographic features.

bundle install
bundle exec appraisal rake test

How to contribute

See CONTRIBUTING.

Contributors

See AUTHORS.

License

See LICENSE.

ruby-jwt's People

Contributors

ab320012 avatar aj-michael avatar anakinj avatar andyjdavis avatar bellebaum avatar codemonkeysteve avatar emiliocristalli avatar excpt avatar gobinathal avatar jamesstonehill avatar johnnyshields avatar jonmchan avatar julik avatar korstiaan avatar lautis avatar martinemde avatar matteopierro avatar n-studio avatar nickhammond avatar ogonki-vetochki avatar petergoldstein avatar phlegx avatar progrium avatar rewritten avatar richardlarocque avatar sporkmonger avatar threedaymonk avatar tpickett66 avatar yasonk avatar zhanghandong avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

ruby-jwt's Issues

Verify ISS should be off by default

It looks like 1.4.0 adds a new feature to verify the iss claim. The problem is that this feature is enabled by default, so if existing code doesn't specify an iss value for the options then the verification fails.

It seems that for backwards compatibility :verify_iss should be false.

ECDSA signature verification fails for valid tokens

ruby-jwt fails with a Signature verification failed (JWT::VerificationError) error when decoding a valid JWT signed with ES512. I believe this is due to an issue with improper ECDSA signature serialization format where the signature parameters are not concatenated in the proper order. The improper serialization results in an implementation being able to successfully verify its own JWTs but not those generated by other conforming libraries.

We encountered the same issue and fixed it on PyJWT a little while ago but some users are now reporting issues with ruby-jwt validating ECDSA-signed tokens and I wanted to pass along the information. PyJWT now has tests validating it against RFC 7520 test vectors to ensure all algorithms serialize properly. It may be a good idea to do a similar thing here.

Ruby test (using ruby-jwt):

require 'jwt'

token = 'eyJhbGciOiJFUzUxMiIsInR5cCI6IkpXVCJ9.eyJoZWxsbyI6IndvcmxkIn0.AQx1MqdTni6KuzfOoedg2-7NUiwe-b88SWbdmviz40GTwrM0Mybp1i1tVtmTSQ91oEXGXBdtwsN6yalzP9J-sp2YATX_Tv4h-BednbdSvYxZsYnUoZ--ZUdL10t7g8Yt3y9hdY_diOjIptcha6ajX8yzkDGYG42iSe3f5LywSuD6FO5c'
pubkey_pem = "-----BEGIN PUBLIC KEY-----\nMIGbMBAGByqGSM49AgEGBSuBBAAjA4GGAAQAcpkss6wI7PPlxj3t7A1RqMH3nvL4\nL5Tzxze/XeeYZnHqxiX+gle70DlGRMqqOq+PJ6RYX7vK0PJFdiAIXlyPQq0B3KaU\ne86IvFeQSFrJdCc0K8NfiH2G1loIk3fiR+YLqlXk6FAeKtpXJKxR1pCQCAM+vBCs\nmZudf1zCUZ8/4eodlHU=\n-----END PUBLIC KEY-----"

pubkey = OpenSSL::PKey::EC.new pubkey_pem
JWT.decode token, pubkey

Python test (using pyjwt):

import jwt

token = 'eyJhbGciOiJFUzUxMiIsInR5cCI6IkpXVCJ9.eyJoZWxsbyI6IndvcmxkIn0.AQx1MqdTni6KuzfOoedg2-7NUiwe-b88SWbdmviz40GTwrM0Mybp1i1tVtmTSQ91oEXGXBdtwsN6yalzP9J-sp2YATX_Tv4h-BednbdSvYxZsYnUoZ--ZUdL10t7g8Yt3y9hdY_diOjIptcha6ajX8yzkDGYG42iSe3f5LywSuD6FO5c'
pubkey_pem = '-----BEGIN PUBLIC KEY-----\nMIGbMBAGByqGSM49AgEGBSuBBAAjA4GGAAQAcpkss6wI7PPlxj3t7A1RqMH3nvL4\nL5Tzxze/XeeYZnHqxiX+gle70DlGRMqqOq+PJ6RYX7vK0PJFdiAIXlyPQq0B3KaU\ne86IvFeQSFrJdCc0K8NfiH2G1loIk3fiR+YLqlXk6FAeKtpXJKxR1pCQCAM+vBCs\nmZudf1zCUZ8/4eodlHU=\n-----END PUBLIC KEY-----'

jwt.decode(token, pubkey_pem)

set token to expire

Is it possible to set an expiration date on the token? Or do we have to do this manually by specifying a header key and comparing that ourselves with the current date?

Support verifying signature signed using x5c header

It is currently possible to verify the signature of a jwt token using the x5c header by providing a key finder function. e.g.

jwt_token = ::JWT.decode(token) do |headers|
  OpenSSL::X509::Certificate.new((headers['x5c'].first)).public_key
end

In order to validate the x5c certificate chain in full, I must provide my own implementation. It would be great if ruby-jwt gem could support the validation of the x5c certificate chain natively.

Here is an excerpt from https://tools.ietf.org/html/draft-ietf-jose-json-web-key-41#section-4.7

4.7. "x5c" (X.509 Certificate Chain) Parameter

The "x5c" (X.509 Certificate Chain) member 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 ([RFC4648] Section 4 -- 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.

Options hash uses both symbols and strings as keys.

I tried to verify the issuer on a JWT that I was decoding today, and I found this line (and others like it) very ugly.

if options[:verify_iss] && options['iss']

This means that my code to decode the JWT looked like this:

JWT.decode(token, public_key, true, :verify_iss => true, 'iss' => 'my issuer')

In my opinion, the consumer of this API should be be able to do one of the following:

  1. Always use symbols as keys in the options hash.
  2. Always use strings as keys in the options hash.
  3. Be able to either use symbols or keys in the options in hash and have our library deal with it under the hood.

Thoughts?

Add a changelog

I was just notified that version 1.5.2 has been released and I'm finding it difficult to evaluate whether or not to make it a priority to upgrade the version I'm using, because there is a lot of changed code and many commits to evaluate. A changelog summarizing the major changes in new versions and what they mean to users would be very nice to have.

I'm willing to work on putting it together, but I'm sure I'll need to bug somebody with lots of questions.

Thanks for the great library!

verify_rsa no method 'verify' for class String

I recently switched my encoding algorithm from HS256 to RS256 and can no longer verify my tokens. Line 59 in jwt.rb seems to be the problem:

public_key.verify(OpenSSL::Digest.new(algorithm.sub('RS', 'sha')), signature, signing_input)

raises a no method error, no method 'verify' for type String. My public key is a string (no sure what else it should be?), and I don't see verify defined anywhere. What am I missing?

Thanks!

Needs to support asymmetric key signatures over shared secrets

Currently, you are using a shared secret to validate the signature of the JWT messages. This entirely defeats the purpose of signing the message and would only be suitable if you were encrypting and not signing the message. The idea behind signing a message is that only the originator can generate the signature and that signature can be validated but not forged. In your implementation any node that needs to validate a signature must in turn be able to forge new ones, because it must know the shared secret.

Therefore, ruby-jwt should allow for the use of asymmetric key based signature generation and checking as outlined in the ruby stdlib OpenSSL documentation here: http://ruby-doc.org/stdlib-2.0/libdoc/openssl/rdoc/OpenSSL.html#module-OpenSSL-label-Signatures. This will allow JWT consumers to verify requests without the ability to forge new ones.

signatures calculated incorrectly (hexdigest instead of digest)

Hi,

Thanks for writing this gem! I'm working on the Java implementation of JWT, using the outputs of your Ruby gem to sanity check my results. I ran into an incompatibility and traced it to your use of OpenSSL::HMAC.hexdigest instead of OpenSSL::HMAC.digest (which is what the spec intends).

This is the spec I'm using:
http://self-issued.info/docs/draft-jones-json-web-token-01.html#anchor10

Your call to hexdigest() is in line 16 of jwt.rb.

Here's an example to illustrate the difference:
ruby-1.8.7-p302 > key = "abcdefghijklmnop"
=> "abcdefghijklmnop"
ruby-1.8.7-p302 > msg = "eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ"
=> "eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ"
ruby-1.8.7-p302 > base64url_encode(OpenSSL::HMAC.digest(OpenSSL::Digest::Digest.new('sha256'), key, msg))
=> "Hp4r9or7FRoPXBtCBbQmU3gxrR2d_rDq_2ZGqeshh4A"
ruby-1.8.7-p302 > base64url_encode(OpenSSL::HMAC.hexdigest(OpenSSL::Digest::Digest.new('sha256'), key, msg))
=> "MWU5ZTJiZjY4YWZiMTUxYTBmNWMxYjQyMDViNDI2NTM3ODMxYWQxZDlkZmViMGVhZmY2NjQ2YTllYjIxODc4MA"

Please let me know if you disagree, or are using a different spec.

Mikhail

Is it possible to decode the payload without validating the signature?

Is it possible to decode the payload without validating the signature?

c="eyJpZCI6MSwidHlwZSI6Im1hbmFnZW1lbnQiLCJpYXQiOiIyMDE1LTA4LTA2VDE1OjA3OjEyLjM3MFoiLCJleHAiOjE0MzkxMzI4MzJ9"

Base64.decode64(c)
"{\"id\":1,\"type\":\"management\",\"iat\":\"2015-08-06T15:07:12.370Z\",\"exp\":1439132832}"

I tried using the Base64 lib, but it returns the result in an escaped formatted string

TypeError when specifying a wrong algorithm

So I ran my usual tests against tampered keys and I got a TypeError under MRI (2.0):

  1. Provide a tampered token with "alg": "HSMAC" (with a valid signature)
  2. Try to verify the token with an RSA public key
  3. TypeError: no implicit conversion of OpenSSL::PKey::RSA into String

I've monkeypatched my app to also rescue TypeError and not just DecodeError but this is just a temporary solution. Interestingly the error does not appear under JRuby.

I've recently read the article about possible security flaws in the library.
I really liked the suggestion to also pass the algorithm and not just the key when verifying the token. Any thoughts on that?

Incorrect readme for leeway

Readme incorrect parameter documentation, missing hash rocket

specs:
ln:155 decoded_payload = JWT.decode(jwt, secret, true, {:leeway => 3})
readme:
JWT.decode(jwt_payload, 'secret', true, leeway=10)

Update gem to get latest changes

Hello,

I must check the algorithm found in the token to avoid some errors, because you can encode with HMAC or RSA, but if we choose RSA, we use #encode where the shared secret is an instance of RSA, and the problem it's that is different it's a string when we choose HMAC.

Because I store the shared secret in my DB, I want to make restriction on the availables algorithms.

Could you please update your gem, because my current answer to this problem require to get access your latest added method #decoded_segments.

JWT.encode({"exp": 10}, "secret")

This seems to be not working. I am using gem 'jwt', ~> 1.2.0

Error Message
SyntaxError: (irb):3: syntax error, unexpected ':'
JWT.encode({"exp": 10}, "ssss" )

url safe encode and decode

This issue pops up when I am trying to make a JWT assertion to a service that isn't implemented using this gem. I think there may be an issue with base64url_encode.

body = JWT.encode({'foo' => 'bar'}, nil, nil).split('.').last
=> "eyJmb28iOiJiYXIifQ"
Base64.decode64(body)
=> "{\"foo\":\"bar\""

Shouldn't there be a closing curly brace on the above? I think you can use Base64.urlsafe_encode64 and Base64::urlsafe_decode64 instead of what you are doing in lines 38-45. I can submit a pull request with this unless there are any objections.

Digest::Digest is deprecated; use Digest

In Rails 4.2.4, I see this warning from the OpenSSL call within encode when testing use rspec:

/opt/rubystack-2.2.3-2/ruby/lib/ruby/2.2.0/openssl/digest.rb:64
/opt/rubystack-2.2.3-2/ruby/lib/ruby/2.2.0/openssl/digest.rb:64:in `initialize'
/opt/rubystack-2.2.3-2/ruby/lib/ruby/gems/2.2.0/gems/jwt-0.1.8/lib/jwt.rb:33:in `new'
/opt/rubystack-2.2.3-2/ruby/lib/ruby/gems/2.2.0/gems/jwt-0.1.8/lib/jwt.rb:33:in `sign_hmac'
/opt/rubystack-2.2.3-2/ruby/lib/ruby/gems/2.2.0/gems/jwt-0.1.8/lib/jwt.rb:16:in `sign'
/opt/rubystack-2.2.3-2/ruby/lib/ruby/gems/2.2.0/gems/jwt-0.1.8/lib/jwt.rb:53:in `encode'
Digest::Digest is deprecated; use Digest

JWT.encode({"exp": 10}, "secret")

This seems to be not working. I am using gem 'jwt', ~> 1.2.0

Error Message
SyntaxError: (irb):3: syntax error, unexpected ':'
JWT.encode({"exp": 10}, "ssss" )

The behavior using 'json' differs from 'multi_json'

Having in mind I just started with JWT a while ago, I see a difference between the two.

Back on node, I could save a simple integer as payload or even a string.

Here, I can do that also if I have multi_json but if not, it raises an exception so I am forced to save a hash.

It is not that important but it bugged me a while.

What do you think?

change to signature of JWT.decode method

JWT.decode can now, since the inclusion of MultiJson, raise a MultiJson::Decode error from lines 67 and 68. This means that he method signature of decode has changed to raise both JWT::DecodeError and MultiJson::DecodeError. Was this change intentional? It's breaking some test cases of mine that expect a JWT::DecodeError to be raised.

Suggest passing block to JWT.decode for claim verification

The current method for verifying the JTI field in the token payload is only useful when the JTI value to compare against is known a priori (when making the call to JWT.decode).

Summary: Using a block parameter or callback on JWT.decode to verify claims (passing the decoded payload/claims) would be more flexible and nicer API IMHO

When the JTI value is dependent on information in the token payload (for example a user object found using a user_id field in the payload), then we can't pass the expected JTI value in the options hash to JWT.decode. In this case we don't know the expected value until after the token has been decoded. The same goes for comparing a JTI value to a blacklist.

The usefulness of the options {verify_jti: true, jti: 'expected-value'} passed to JWT.decode is limited. Maybe the same goes for iss, aud and sub.

May I suggest an alternative API for verification of jti, iss, aud and sub which is to pass an (anonymous) block to JWT.decode for verification. The payload would be passed as parameters to the block. When the block returns falsey, then JWT.decode would raise a JWT::VerificationError.

For example: Given the following verification function ...

def valid_token?(payload)
  valid_user?(payload['user']['id']) && !blacklisted?(payload['jti'])
end

... with the current API I have to do:

payload, header = JWT.decode(token, 'my-jwt-secret')
valid_token?(payload) || raise AuthenticationError # application specific exception

... With a verification block this would become:

JWT.decode(token, 'my-jwt-secret') do |payload|
  valid_token?(payload)
end # when valid_token? return falsey raises JWT::VerificationError (for example)

The current verfication of the exp, nbf and iat claims is unambiguous so it can be handled in JWT.decode with the current flag-and-expected-value-in-options-hash method. But I would prefer the block method to be the only method to verfiy claims. Special 'build-in' methods could be used for verification of exp, nbf and iat claims.

JWT.decode(token, 'my-jwt-secret') do |payload, header|
  valid_exp?(payload['exp']) && \ # built-in
  valid_nbf?(payload['nbf']) && \ # built-in
  valid_iat?(payload['iat']) && \ # built-in
  valid_token?(payload) # user defined
end # when valid_token? return falsey raises JWT::ValidationError (for example)

This method doesn't require a separate flags to indicate which claims to verify.

Sorry this has gotten a bit long. I hope I explained well.

Shouldn't verification of additional claims, like iss, aud etc. be enforced when in options?

First of all - thanks for the great gem!

What I've stumbled upon while using the gem is the verification of additional attributes, like e.g. the "iss" claim. When "iss" is supplied to the options in JWT.decode it is not enforced or checked, even when verify_iss is set to true as long as it's not present in the actual payload. Basically I've had the following decoding code:

options = {
  algorithm: 'HS256',
  verify_iss: true,
  'iss' => 'acme.org'
}
payload, = JWT.decode(token, "secret", true, options)

and provided it a token like:

token = JWT.encode({ data: 'payload' }, 'secret', 'HS256')

and expected it to raise an error, because iss is not set in the payload - is this assumption wrong? Should the presence of these attributes be verified again by the application? Looking at jwt.rb#166 the issuer is only verified when it's present in the payload. From my point of view - and I think the more "safe" variant - would be to always trust the options and when "iss" is present in the options then enforcing the check against the issuer.

PS: I'm not savvy with the JWT spec, so it can be that the JWT spec actually proposes the current design. Then just ignore & close my issue :)
PPS: And if this proposal makes sense, I'd be happy to create a PR

What is audience?

What exactly is aud (audience)? Can this represent roles of the user session / owner of the token? i.e. admin, guest, etc?

Semantic versioning

The last release included an incompatible change to JWT's interface which broke several of my projects. Any chance we could switch to semantic versioning so that consumers of this API don't unsuspectingly upgrade to incompatible versions?

Must we specify algorithm when calling decode to avoid vulnerabilities?

First of all, cool library. I was reading through the closed issues, and noticed #76. It seems to suggest that in order to be sure you are safe from this vulnerability affecting RSA and ECDSA algorithms, you need to specify the algorithm when decoding a JWT, like so: JWT.decode(token, key, true, algorithm: 'RS512'). So I then read through the readme for this library, but did not see this algorithm parameter mentioned anywhere in the readme. So now I'm confused and a little concerned.

Has the need to specify the optional algorithm parameter been removed due to a commit somewhere that made this library more secure by default? (That would be good)
Or must users specify this optional, undocumented algorithm parameter in order to be secure? (That would be bad)

If the latter is the case, I'm happy to help update the docs to clearly explain the algorithm needs to be passed in to keep things more secure.

Catch up for ActiveWhatever 4.1.1 series

When upgrading to Active* 4.1.1 my bundle quits on jwt 0.1.12 not being found.
For now I am adding this to my Gemfile:

 gem "jwt",  "0.1.12", :git => 'https://github.com/progrium/ruby-jwt.git', :tag => 'jwt-0.1.12'  

Any idea when this gem will hit rubygems at that version?

decode fails with 'none' algorithm and verify

When providing a token that has the algorithm 'none' to the decode method, a decode error is raised from line 87 with the error message 'Not enough or too many segments'.

This can be suppressed by disabling verification when decoding, but that has knock-on effects of other claims not being verified.

I believe the correct behaviour should be that, when the algorithm is 'none' and the token is otherwise valid, the decode method should return successfully.

It is worth noting that this behaviour provides (accidentally, I believe) protection against certain attacks. To provide support for this without exposing users to additional vulnerabilities, I would suggest also adding some flag (that defaults safely) that allows the developer to 'turn on' acceptance of the 'none' algorithm.

Release a new version

Can you please release a new version? The latest version in the gem repository does not include the exp claim implementation which is really practical. :)

aud verifies if aud is passed in, :sub does not

If you pass in :aud and :verify_aud, then it will fail if :aud is not in the payload.

the equivalent is not true for :sub. If you pass in :sub but it is not in the payload, it won't do anything. I would expect the behavior of :aud, which is if you ask to verify_sub, it will fail if it isn't in the payload.

if that sounds reasonable, I'll submit a patch. thanks!

Fix either README or source code

I found that README has incorrect (not yet implemented) examples.
I do use the iss check in the app and implemented it using my wrapper class.

After the 1.5 released, I removed the wrapper and tested the jwt gem. It appears that it requires special "setup" before:
5c09aad#commitcomment-11125584

Release

When will we get the next release?

jti verification not working per the spec

The jti verification implemented here supports a variant of the spec, but is far to limited to a specific use case.

The spec (see https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-32#section-4.1.7) stipulates that the claim should be a unique ID, but not an algorithm for generating such a unique ID. The supported verification here would enforce a specific algorithm, requiring an iat claim to be present as well as a key.

The iat claim is optional and unrelated to the jti claim in the spec and the key may either not exist in the case of an unsecured JWT or be unknown to the sender in the case of an asymmetric signing or encryption algorithm being used.

The iat claim is also defined as the integer number of seconds since epoch. This means that its use as a nonce to prevent replay isn't particularly valid. Given that it cannot be assumed that this is unique from an issuer, which may be issuing thousands of tokens with the same secret per second, adding this is quite limiting.

Further, the current implementation requires the developer to know the key, iat value for the JWT and also the algorithm used to generate the jti claim in order to decode the token.

The implementation provided for the jti verification is application-specific, so probably doesn't belong in a library such as this.

An alternative implementation might be to delegate verification of the uniqueness of the token to the application through a callback.

API request - JWT::decoded_header()

It would be useful is the different segments can be exposed like a public getter that returns header = MultiJson.decode(base64url_decode(header_segment)). I need the header to extract the thumbprint and use the right secret to verify signature.

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.