william_johnson

  Will Johnson is a Developer Advocate at Auth0. He loves teaching topics in a digestible way to empower more developers. He writes blog posts, records screencasts, and writes eBooks to help developers. He's also an instructor on <a target='_blank' rel='noopener noreferrer' href='https://egghead.io'><strong><b>egghead.io</b></strong></a>.


Developer Advocate

Will Johnson

Learn the difference between RS256 and HS256 JWT signing algorithms

When learning about JWTs, some terms you hear a lot are signatures and signing. If the tutorials are creating JWTs, you may see them select an algorithm to create the signature. But what are signing algorithms, and how do they work? Read further to learn the differences between the two most common algorithms, and which one is recommended to use in applications.

If you prefer, you can watch the video below with me explaining the differences between two JWT signing algorithms! 👇

<AmpContent>
<amp-youtube
    data-videoid="iSStmRn05nA"
    layout="responsive"
    width="480" height="270">
</amp-youtube>
</AmpContent>

<NonAmpContent>
<div
  class='embed-container'
  style="position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden; max-width: 100%;margin-bottom:40px;">
    <iframe
      style="position: absolute; top: 0; left: 0; width: 100%; height: 100%;"
      src='https://www.youtube.com/embed/iSStmRn05nA'
      frameborder='0' allowfullscreen>
    </iframe>
</div>
</NonAmpContent>

## What are JWT signatures?

When you create JSON Web Tokens, they are signed. Signing the token allows its recipient to validate that the content of the token wasn't changed and verify the original issuer of the token created signature.

<div class="alert alert-success alert-icon"> Heads up! Signatures are not encryptions! </div>

Signing JWTs doesn't make their data unreadable. Signatures only verify that the content of the JWT was not changed. 

The signature is the part of a JWT that verifies the content of the JWT hasn't changed since the moment it has been issued (as it would happen, for example, in [bucket brigade attacks](https://auth0.com/docs/secure/security-guidance/prevent-threats#bucket-brigade-attacks) formerly known as "man or person in the middle" attacks).

RS256 and HS256 are the most common algorithms used for signing JWTs. This article will go over some differences between RS256 and HS256. This post will not cover the other JWT signing algorithms, such as ES256 or PS256.

> To view more signing algorithims this link to the specs that [lists all the signing algorithms](https://datatracker.ietf.org/doc/html/rfc7518#section-3).

### How are JWT signatures crated?

Signatures are created by combining encoded versions of the **header** and **payload** of a JWT, passing them and the secret as parameters into the algorithm defined in the header.

The following is an example code that can be used to create a JWT signature.

```js
HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)
```

The following is an example output of what the signed JWT looks like:


```bash
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
```
Each section(header, payload and signature) is separated by a period(.).

The following picture highlights the signature part of a JWT decoded via [jwt.io](https://jwt.io/):

![jwt.io](https://images.ctfassets.net/23aumh6u8s0i/4iwiyrQaM62KhBTQfdVT78/230fb46d33eec8f88c2f664979054098/jwt-io-verify-signature.jpeg)

JWTs are commonly signed using one of two algorithms: HS256 (HMAC using SHA256) and RS256 (RSA using SHA256).

That leaves you with the question:

*What's the difference between RS256 and HS256 signing algorithms?*

## HS256 Signing Algorithm

HS256 (HMAC with SHA-256) is a symmetric keyed hashing algorithm that uses one **secret key**. Symmetric means two parties share the secret key. The key is used for both generating the signature and validating it.

Be mindful when using a shared key; it can open potential vulnerabilities if the verifiers(multiple applications) are not appropriately secured.  

> Read more about keyed hashes vs signatures on [this stackexchange question](https://crypto.stackexchange.com/questions/5646/what-are-the-differences-between-a-digital-signature-a-mac-and-a-hash)


## RS256 Signing Algorithm

RS256 (RSA Signature with SHA-256) is an asymmetric algorithm that uses a public/private key pair. The identity provider has a private key to generate the signature. The receiver of the JWT uses a public key to validate the JWT signature. The public key used to verify and the private key used to sign the token are linked since they are generated as a pair. Check out this blog post to get an [introduction to Public-Key Cryptography](https://auth0.com/blog/how-to-explain-public-key-cryptography-digital-signatures-to-anyone/)

> **NOTE:** In both cases, a third party could potentially find your secret key and generate a JWT that would be considered valid for your application. In the case of the HS256 algorithm, verifiers (applications) of tokens have the same key that signs a JWT, which increases the risk of being exposed to a third party. You would need to take caution to protect the key from being compromised, such as putting the secret in a secure store, limiting access to it, etc.

<include src="SignupCTA" text="Try out the most powerful authentication platform for free." linkText="Get started →" />

## RS256 or HS256? Which Should You Use?

While both HS256 and RS256 can be used to verify the integrity of JWTs, the recommended algorithm at this time is RS256.

A signature must ensure authenticity, which means that the JWT content is the same as that generated by the sender. Both HS256 and RS256 algorithms ensure JWT authenticity.

RS256 also ensures non-repudiation, which means it guarantees that the sender has generated the signature.

With RS256, you are sure only the holder of the private key and no one else can sign tokens. In addition, if the secret key is compromised, you can rotate signing keys without re-deploying your application with a new secret, as you would have to do with HS256.

Keep in mind that regularly rotating keys is good even when keys aren't compromised. Rotating keys reduces the chance of a compromise. For example, Auth0 notifies you if you haven't rotated your key in more than 365 days.

You might be wondering if there is any scenario where you would choose HS256? Great question! And yes, there are a couple of situations where you may use HS256. 

You could consider using HS256 when working on legacy applications that can't support RS256. Another possible use case for using HS256 instead of RS256 is when your application makes a very large number of requests because HS256 is more efficient than RS256.

## Summary 

In this article, you learned some key differences between the HS256 and RS256 signing algorithms for JWTs, which are as follows:

* HS256 is a symmetric algorithm that shares one secret key between the identity provider and your application. The same key is used to sign a JWT and verify that signature.

* RS256 algorithm is an asymmetric algorithm that uses a private key to sign a JWT and a public key to verify that signature.

* RS256 is the recommended algorithm when signing your JWTs. It is more secure, and you can rotate keys quickly if they are compromised. (Auth0 signs JWTs with RS256 by default). 

You can learn more about [how signing keys work by reading the Auth0 docs](https://auth0.com/docs/get-started/tenant-settings/signing-keys).

RS256 vs HS256: What's The Difference?

dfea5c5f769cc4a6cce74d3eda20bba3?size=200 avatar

dfea5c5f769cc4a6cce74d3eda20bba3?size=200

Guest Author

Tim McLean

Which libraries are vulnerable to attacks and how to prevent them.



**TL;DR:** If you are using [node-jsonwebtoken](https://github.com/auth0/node-jsonwebtoken), [pyjwt](https://github.com/jpadilla/pyjwt/), [namshi/jose](https://github.com/namshi/jose), [php-jwt](https://github.com/firebase/php-jwt) or [jsjwt](https://github.com/kjur/jsjws) with asymmetric keys (RS256, RS384, RS512, ES256, ES384, ES512) please update to the latest version. See [jwt.io](http://jwt.io) for more information on the vulnerable libraries. *(Updated 2015-04-20)*

> This is a guest post from Tim McLean, who is a member of the [Auth0 Security Researcher Hall of Fame](https://auth0.com/whitehat#hall-of-fame). Tim normally blogs at [www.timmclean.net](https://www.timmclean.net).

Recently, while reviewing the security of various JSON Web Token implementations, I found many libraries with critical vulnerabilities allowing attackers to bypass the verification step.  The same two flaws were found across many implementations and languages, so I thought it would be helpful to write up exactly where the problems occur.  I believe that a change to the standard could help prevent future vulnerabilities.

<include src="TweetQuote" quoteText="I found many libraries with critical vulnerabilities allowing attackers to bypass the verification step."/>

For those who are unfamiliar, [JSON Web Token (JWT)](https://auth0.com/learn/json-web-tokens/) is a standard for creating tokens that assert some number of claims.  For example, a server could generate a token that has the claim "logged in as admin" and provide that to a client. The client could then use that token to prove that they are logged in as admin. The tokens are signed by the server's key, so the server is able to verify that the token is legitimate.

JWTs generally have three parts: a header, a payload, and a signature.

The header identifies which algorithm is used to generate the signature, and looks something like this:

``` javascript  
header = '{"alg":"HS256","typ":"JWT"}'
```

`HS256` indicates that this token is signed using HMAC-SHA256.

The payload contains the claims that we wish to make:

``` javascript  
payload = '{"loggedInAs":"admin","iat":1422779638}'
```

As suggested in the JWT spec, we include a timestamp called `iat`, short for "issued at".

The signature is calculated by base64url encoding the header and payload and concatenating them with a period as a separator:

``` javascript  
key = 'secretkey'
unsignedToken = encodeBase64(header) + '.' + encodeBase64(payload)
signature = HMAC-SHA256(key, unsignedToken)
```

To put it all together, we base64url encode the signature, and join together the three parts using periods:

``` javascript  
token = encodeBase64(header) + '.' + encodeBase64(payload) + '.' + encodeBase64(signature)

# token is now:
# eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJsb2dnZWRJbkFzIjoiYWRtaW4iLCJpYXQiOjE0MjI3Nzk2Mzh9.gzSraSYS8EXBxLN_oWnFSRgCzcmJmMjLiuyu5CSpyHI
```

To learn more about JSON Web Tokens, check out our free ebook below.

<include src="ebook-ads/JwtHandbook" />

## Great. So, What's Wrong with That?

Well, let's try to verify a token.

First, we need to determine what algorithm was used to generate the signature. No problem, there's an `alg` field in the header that tells us just that.

But wait, we haven't validated this token yet, which means that we haven't validated the header.  This puts us in an awkward position: in order to validate the token, we have to allow attackers to select which method we use to verify the signature.

This has disastrous implications for some implementations.

## Meet the "None" Algorithm


The `none` algorithm is a curious addition to JWT.  It is intended to be used for situations where the integrity of the token has already been verified. Interestingly enough, it is one of only two algorithms that are mandatory to implement (the other being `HS256`).

Unfortunately, some libraries treated tokens signed with the `none` algorithm as a valid token with a verified signature.  The result?  Anyone can create their own "signed" tokens with whatever payload they want, allowing arbitrary account access on some systems.

Putting together such a token is easy. Modify the above example header to contain `"alg": "none"` instead of `HS256`.  Make any desired changes to the payload.  Use an empty signature (i.e. `signature = ""`).

Most (hopefully all?) implementations now have a basic check to prevent this attack: if a secret key was provided, then token verification will fail for tokens using the `none` algorithm.  This is a good idea, but it doesn't solve the underlying problem: attackers control the choice of algorithm.  Let's keep digging.

## RSA or HMAC?

The JWT spec also defines a number of asymmetric signing algorithms (based on RSA and ECDSA).  With these algorithms, tokens are created and signed using a private key but verified using a corresponding public key.  This is pretty neat: if you publish the public key but keep the private key to yourself, only you can sign tokens, but anyone can check if a given token is correctly signed.

Most of the JWT libraries that I've looked at have an API like this:

``` javascript  
# sometimes called "decode"
verify(string token, string verificationKey)
# returns payload if valid token, else throws an error
```

In systems using HMAC signatures, `verificationKey` will be the server's secret signing key (since HMAC uses the same key for signing and verifying):

``` javascript  
verify(clientToken, serverHMACSecretKey)
```

In systems using an asymmetric algorithm, `verificationKey` will be the public key against which the token should be verified:

``` javascript  
verify(clientToken, serverRSAPublicKey)
```

Unfortunately, an attacker can abuse this.  If a server is expecting a token signed with RSA, but actually receives a token signed with HMAC, **it will think the public key is actually an HMAC secret key**.

How is this a disaster?  HMAC secret keys are supposed to be kept private, while public keys are, well, public.  This means that your typical [ski mask-wearing attacker](https://i.imgur.com/18fM5ja.jpg) has access to the public key, and can use this to forge a token that the server will accept.

Doing so is pretty straightforward.  First, grab your favorite JWT library, and choose a payload for your token.  Then, get the public key used on the server as a verification key (most likely in the text-based PEM format). Finally, sign your token using the PEM-formatted public key as an HMAC key. Essentially:

``` javascript  
forgedToken = sign(tokenPayload, 'HS256', serverRSAPublicKey)
```

The trickiest part is making sure that `serverRSAPublicKey` is identical to the verification key used on the server.  The strings must match exactly for the attack to work -- exact same format, and no extra or missing line breaks.

End result?  Anyone with knowledge of the public key can forge tokens that will pass verification.

## Recommendations for Library Developers

I suggest that JWT libraries add an `algorithm` parameter to their verification function:

``` javascript  
verify(string token, string algorithm, string verificationKey)
```

The server should already know what algorithm it uses to sign tokens, and it's not safe to allow attackers to provide this value.

Some might argue that some servers need to support more than one algorithm for compatibility reasons.  In this case, a separate key can (and should) be used for each supported algorithm.  JWT conveniently provides a "key ID" field (`kid`) for exactly this purpose.  Since servers can use the key ID to look up the key and its corresponding algorithm, attackers are no longer able to
control the manner in which a key is used for verification.  In any case, I don't think JWT libraries should even look at the `alg` field in the header, except maybe to check that it matches what the expected algorithm was.

Anyone using a JWT implementation should make sure that tokens with a different signature type are guaranteed to be rejected.  Some libraries have an optional mechanism for whitelisting or blacklisting algorithms; take advantage of it, or you might end up at risk.  Even better: have a policy of performing security audits on any open source libraries that you use to provide mission-critical functionality.

## Improving the JWT/JWS Standard

I would like to propose deprecating the header's `alg` field.  As we've seen here, its misuse can have a devastating impact on the security of a JWT/JWS implementation.  As far as I can tell, key IDs provide an adequate alternative. This warrants a change to the spec: JWT libraries continue to be written with security flaws due to their dependence on `alg`.

JWT (and JOSE) present the opportunity to have a cross-platform suite of secure cryptography implementations.  With these fixes, hopefully, we're a little bit closer to making that a reality.

<include src="asides/Jwt" />


Critical vulnerabilities in JSON Web Token libraries

kapehe-jorgenson

Kapehe is an R&D Content Engineer for Auth0 with a passion for learning and teaching. With her primary focus on ReactJS and JavaScript, she is impressed with what code can create for the web. Technology and web development are constantly evolving and naturally bring that need for continual learning. She enjoys writing tutorials, hosting local meetups, and learning with others to expand coding knowledge.

R&D Content Engineer

Kapehe Jorgenson

Auth0's Kapehe Jorgenson, Dasha Nikitina, and Dorrin Poorkay lead an Algorithm session at WWC - CONNECT 2019.



Women Who Code - CONNECT 2019 was held on April 13, 2019 at the [Pinterest](https://www.pinterest.com/) headquarters in San Francisco, California. This event was sponsored by some of the largest names in tech: [Auth0](https://auth0.com/), [PayPal](https://www.paypal.com/us/home), [Atlassian](https://www.atlassian.com/), [Cisco Umbrella](https://umbrella.cisco.com/), and [LinkedIn](https://www.linkedin.com/), just to name a few.

![Welcome Talk at Women Who Code - CONNECT 2019](https://images.ctfassets.net/23aumh6u8s0i/gv8GVhSlZnHFZDCncbMNl/a947e750accaaad10a2a7a17224da124/intro-talk)

When a whiteboarding session opened up and the offer was extended to UI Engineer [Dasha Nikitina](https://www.linkedin.com/in/darianikitina/), Platform Engineer [Dorrin Poorkay](https://www.linkedin.com/in/dorrin-poorkay-94552b82/), and myself, R&D Content Engineer [Kapehe Jorgenson](https://auth0.com/blog/authors/kapehe-jorgenson/), to fill in and lead it, we jumped on the opportunity. The whiteboarding session was on Algorithms and Interviews, officially named "Algorithms (Why Do We Care)". We were confident that we could collaborate and deliver a session worth coming to with our unique interview experiences.

## Remotely Connected

Being a remote-friendly company, this was going to be the first time that Dasha, Dorrin, and I were going to be in the same room at the same time. We are always connected virtually and Auth0 keeps the close culture alive, yet this was new. I had recently interviewed Dorrin and learned all about [her empowering journey](https://auth0.com/blog/meet-the-experts-dorrin-poorkay/) as an engineer on the Auth0 team.

Dasha has also been working very closely with my team and with her UI engineering skills has revamped the entire [Auth0 blog](https://auth0.com/blog/). She succeeded in delivering a beautiful product that I know will be beneficial to our users.

When we finally met each other face-to-face, it was as if we didn't work remotely, but saw each other everyday in the office.

## Alaina Percival, Women Who Code CEO

Celebrating women in tech, CEO of Women Who Code (WWC) [Alaina Percival](https://twitter.com/alaina), offered stats, advice, and encouragement throughout the day to the hundreds of women who attended. Alaina announced that the official count of WWC had reached 180,000 members worldwide.

<AmpContent>
  <include src="TweetQuote" quoteText="Announcement today that @WomenWhoCode have 180,000 members worldwide 🙌💪👩🏽‍💻👩🏻‍💼🙋🏿‍♀️🙋🏼‍♀️ #WWCode &mdash; Women Who Code BFS (@WWCodeBelfast)"/>

</AmpContent>

<NonAmpContent>

  <blockquote class="twitter-tweet" data-lang="en"><p lang="en" dir="ltr">Announcement today that <a href="https://twitter.com/WomenWhoCode?ref_src=twsrc%5Etfw">@WomenWhoCode</a> have 180,000 members worldwide 🙌💪👩🏽‍💻👩🏻‍💼🙋🏿‍♀️🙋🏼‍♀️ <a href="https://twitter.com/hashtag/WWCode?src=hash&amp;ref_src=twsrc%5Etfw">#WWCode</a> <a href="https://twitter.com/hashtag/CONNECT?src=hash&amp;ref_src=twsrc%5Etfw">#CONNECT</a> <a href="https://t.co/e75EV19nR1">pic.twitter.com/e75EV19nR1</a></p>&mdash; Women Who Code BFS (@WWCodeBelfast) <a href="https://twitter.com/WWCodeBelfast/status/1117101032973033472?ref_src=twsrc%5Etfw">April 13, 2019</a></blockquote>
  <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
  
  <include src="TweetQuote" quoteText="Alaina Percival, CEO of Women Who Code, announced that the official count of WWC had reached 180,000 members worldwide."/>

</NonAmpContent>

## Tara Hernandez, Google Engineering Manager

Keynote speaker [Tara Hernandez](https://twitter.com/tequilarista), Engineering Manager for the Google Cloud Platform, gave her talk, titled "Forget Faking It, We're Making It" on the main center stage. Tara talked about her journey on where she is now and how we need to bring more "woman-ness" into the tech industry. Her path showed that with hard work, we don't need to act like men, but celebrate our own uniqueness.

<AmpContent>
  <include src="TweetQuote" quoteText="“We're not faking it, we’re making it!“ - Engineer Manager, Tara Hernandez at #WWCode #CONNECT. @tequilarista &mdash; Women Who Code (@WomenWhoCode)"/>

</AmpContent>

<NonAmpContent>

  <blockquote class="twitter-tweet" data-lang="en"><p lang="en" dir="ltr">“We&#39;re not faking it, we’re making it!&quot; -  <a href="https://twitter.com/Google?ref_src=twsrc%5Etfw">@Google</a> Engineer Manager, Tara Hernandez at <a href="https://twitter.com/hashtag/WWCode?src=hash&amp;ref_src=twsrc%5Etfw">#WWCode</a> <a href="https://twitter.com/hashtag/CONNECT?src=hash&amp;ref_src=twsrc%5Etfw">#CONNECT</a>. <a href="https://twitter.com/tequilarista?ref_src=twsrc%5Etfw">@tequilarista</a> <a href="https://t.co/PGQs4fjMcy">pic.twitter.com/PGQs4fjMcy</a></p>&mdash; Women Who Code (@WomenWhoCode) <a href="https://twitter.com/WomenWhoCode/status/1117109707481722880?ref_src=twsrc%5Etfw">April 13, 2019</a></blockquote>
  <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

</NonAmpContent>

## Auth0's WWC Conference Booth

Auth0's booth, hosted by our very own [Kim Ripperger](https://twitter.com/kimmyripp) and [Trevor Salter](https://twitter.com/TCSalter), received a lot of traffic and dozens of interested individuals in possibly joining Auth0. If you were to head over to our blog post [How We Hire Engineers](https://auth0.com/blog/how-we-hire-engineers/), you could learn about our hiring process. With multiple engineering positions open, our presence at WWC was extremely valuable with the amount of interest we received.

![Auth0 Booth at Women Who Code CONNECT 2019](https://images.ctfassets.net/23aumh6u8s0i/4AK8s2zqwJmBhKkv0mH7IN/f4d20c350cdadd82e4453be5b3996b36/auth0-booth)

## Algorithms (Why Do We Care) - Kapehe, Dasha, Dorrin

At 2:45 pm, we were scheduled to lead the algorithms session. We arrived at our room around 2:10 and within a couple of minutes we had people showing up. The room filled up fast &mdash; every seat was taken and the standing room was going quick. Dasha, Dorrin, and I ended up in the corner of the room leading our session to a packed room.

![Dasha, Kapehe, Dorrin leading the Algorithms session](https://images.ctfassets.net/23aumh6u8s0i/6PsCvMogxBMBsXF9M88S6n/7b9613c4074de29c684b98ded073fe39/algorithms-interview)

The session started off with a discussion on algorithms and the benefit of understanding them when going into any technical interview. The question was asked, "What is an algorithm?" and very quickly an attendee responded with "a set of steps or guidelines on how to complete a job or task." 

Dasha gave the group a visual of [visualgo.net](https://visualgo.net/en) and how a handful of algorithms work. Our group was excited for the resource because it showed a very clear visual of how the sorting was being done in different sorting methods.

We finished off the session with Dasha, Dorrin, and myself sharing our various interview experiences and how whiteboarding, understanding algorithms, and good communication has helped us.

![Algorithm session attendees](https://images.ctfassets.net/23aumh6u8s0i/5iOKK70eZ5qu7pMysSlyNP/b2cf70a7cb2381bbbbfb58c85cfe6cdc/session-attendees)

## Auth0 Women Who Code

Auth0 takes pride in its diversity. Sending four of its women to WWC - Connect 2019 was a great way to represent the company and the value it sees in the women engineers.

![Auth0's Kim Ripperger, Dorrin Poorkay, Kapehe Jorgenson, Dasha Nikitina](https://images.ctfassets.net/23aumh6u8s0i/je4Y38eSqOk0tA2k9Rnod/f8c443ccb22e72bdf00c370fdd83f7cd/auth0-women) 

We are growing rapidly and I feel honored to work for such an inclusive company. Being remotely-friendly, Auth0 is able to give engineering opportunities to women across the globe.

Visit our [career page](https://auth0.com/careers) to learn more about our great engineering opportunities!

<include src="TweetQuote" quoteText="Being remotely-friendly, Auth0 is able to give engineering opportunities to women across the globe."/>

## Take-Away

This was my first time attending Women Who Code - CONNECT and it was fantastic seeing such a powerful organization standing behind 180,000 women in tech. With multiple scholarships being awarded, WWC is empowering women to go for those engineering roles. 

Did you attend WWC - Connect 2019 or were you impacted by a strong woman in tech? Share your experience with us in the discussion section below. We would love to continue to empower you!

<include src="asides/AboutAuth0" />

Women Who Code - CONNECT 2019

99c4080f412ccf46b9b564db7f482907?s=200 avatar

99c4080f412ccf46b9b564db7f482907?s=200

I'm currently a Senior Developer Advocate at MongoDB. I'm also a Google Developer Expert for Web Technologies and spend most my time giving talks at conferences and meetups, mentoring developers and running workshops, and creating online content to help technology professionals.

Former Auth0 Employee

Ado Kukic

Network, catch up on all the big announcements, and grab some swag at Rogue Ales Pub House. The happy hour hosted by Auth0, Algolia, and Keen IO is happening right after the talks end on May 24, 2017.



[Signal.2017](https://www.twilio.com/signal) is less than two weeks away and we can't wait to see what Twilio and the numerous vendors attending will have to show. The two-day conference kicks off May 24 and will be held at Pier 27 in San Francisco, California. After a long day of invigorating sessions including: [IFTTT: Building applications for the future](https://www.twilio.com/signal/schedule/7sIpsjOkTewgygqY86Sc0Y/ifttt-building-applications-for-the-future) by [Linden Tibbets](https://twitter.com/@ltibbets), [Congress on Speed Dial: Advocacy in the age of Twilio](https://www.twilio.com/signal/schedule/6LbXCBBhtYuKCSciyS8WA/congress-on-speed-dial) by [Ian Webster](https://twitter.com/@iwebst), and [What Can You Do With Twilio Voice?](https://www.twilio.com/signal/schedule/4r1gBAICZOAQGEAAascQSi/what-can-you-do-with-twilio-part-2) by [Manav Khurana](https://twitter.com/@manavkhurana), join Auth0, Algolia, and Keen IO as we host a special happy hour for Signal.2017 attendees.

![Signal Website](https://images.ctfassets.net/23aumh6u8s0i/10qrmp8n7s4gPXO0v98RNW/a1096d585fc0d8911d53703d80b15406/signal)

The happy hour will be a great opportunity to meet and network with fellow attendees, talk about all the new announcements, and get some swag. Food and drinks will be provided courtesy of Auth0, Algolia, and Keen IO.

**What**: Auth0, Algolia, and Keen IO Happy Hour

**Where**: Rogue Ales Public House, 673 Union Street, San Francisco, CA 94133

**When**: May 24, 2017 at 7:30pm - 9:30pm

**How**: [RSVP](https://www.eventbrite.com/e/rogue-ales-happy-hour-by-algolia-auth0-and-keen-io-tickets-34586663642) to reserve your spot as space is limited

We can't wait to see you there!

<include src="asides/AboutAuth0" />

### About Algolia

Algolia helps developers connect their users with what matters most. Our hosted search API powers billions of queries for thousands of websites & mobile applications every month, delivering relevant results in an as-you-type search experience in under 100ms anywhere in the world. Algolia's full-stack solution takes the pain out of building search; we maintain the infrastructure & the engine, and we provide extensive documentations to our dozens of up-to-date API clients and SDKs with all the latest search features, so you can focus on delighting your users.

For more information visit [https://www.algolia.com](https://www.algolia.com) or follow [@algolia](https://twitter.com/algolia) on Twitter.

### About Keen IO

Over 60,000 developers use Keen IO APIs to capture, analyze, and embed event data into their tools and products. Thousands of customers rely on Keen’s event data platform to white label data applications in media, e-commerce, adTech, gaming, IoT and retail. Keen’s customers query trillions of data points daily. Keen IO also values and promotes empathy, introspection, distributed innovation, continuous learning, playing to your strengths, and patching your weaknesses with diverse collaborators.

For more information visit [https://keen.io](https://keen.io) or follow [@keen_io](https://twitter.com/keen_io) on Twitter.


Join Auth0, Algolia, and Keen IO for Happy Hour at Signal 2017

001c9ddc5ceb9829b6aaf24f5d28502a

I am software developer with a keen interest in open-source technologies, Linux, and native development. I've worked on many different platforms Android, iOS, Win32, Linux, FreeRTOS, the Web, and others. I've gone through the whole stack and I enjoy learning and using the latest technologies. I now work as a full-stack developer at Auth0.

Senior Engineer

Sebastian Peyrott

Learn all about the different JWT signing algorithms and how to choose the correct one for your use case!



JSON Web Tokens are used in the industry more and more. The spec which defines them ([RFC7519](https://tools.ietf.org/html/rfc7519)) describes them as a compact, URL-safe means of representing claims between parties by encoding them as JSON objects which can be digitally signed or encrypted. There are several algorithms which take place in this process, we will explore some of the most common ones below. Read on!

For an in-depth introduction to JSON Web Tokens, download our **free JWT Handbook** below.

<include src="ebook-ads/JwtHandbook" />

## JSON Web Token
A JSON Web Token encodes a series of *claims* in a JSON object. Some of these claims have specific meaning, while others are left to be interpreted by the users. Common claims are:

- Issuer (iss)
- Subject (sub)
- Audience (aud)
- Expiration time (exp)
- Not before (nbf)
- Issued at (iat)
- JWT ID (jti)

Some of these claims are very common. The subject claim (sub) normally describes to whom or to which application the JWT is issued. The issued at claim (iat) can be used to store the time at which the JWT is created, thus allowing JWTs to be invalidated after a certain amount of time. Other custom claims can be added.

A JWT is usually complemented with a signature or encryption. These are handled in their own specs as [JSON Web Signature (JWS)](https://tools.ietf.org/html/rfc7515) and [JSON Web Encryption (JWE)](https://tools.ietf.org/html/rfc7516).

A signature allows a JWT to be *validated* against modifications. Encryption, on the other hand, makes sure the content of the JWT is only readable by certain parties.

### JOSE header
Signed and encrypted JWTs carry a header known as the JOSE header (JSON Object Signing and Encryption). This header describes what algorithm (signing or encryption) is used to process the data contained in the JWT. The JOSE header typically defines two attributes: `alg` and `typ`.

- alg: the algorithm used to sign or encrypt the JWT
- typ: the content that is being signed or encrypted (usually 'JWT').

### Compact Representation
JWS also defines a *compact* representation for a signed JWT:

```
BASE64URL(UTF8(JWS Protected Header)) + '.' +
BASE64URL(JWS Payload) + '.' +
BASE64URL(JWS Signature)
```

The compact representation is basically the concatenation of the JOSE header, the JWT and the details of the signature. Each component is BASE64 encoded and separated by a single dot ('.').

This results in the typical JWT representation we find in the web:

```
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
```

[jwt.io](http://jwt.io) is an excellent playfield to test JWTs. Go to [http://jwt.io](http://jwt.io) and input the string above in the encoded field.

### Compact Representation for Encrypted JWTs
The compact representation for encrypted JWTs is somewhat different:

```
BASE64URL(UTF8(JWE Protected Header)) + '.' +
BASE64URL(JWE Encrypted Key) + '.' +
BASE64URL(JWE Initialization Vector) + '.' +
BASE64URL(JWE Ciphertext) + '.' +
BASE64URL(JWE Authentication Tag)
```

The ciphertext would normally contain a JWT.

Signed and encrypted JWTs are usually *nested*. That means that a signed JWT is first produced and then an encrypted version of the signed result is then created. This provides two benefits:

- The signature can't be stripped.
- The signature is private (can't be seen by others).

## Common JWT Signing Algorithms
Most JWTs in the wild are just signed. The most common algorithms are:

- HMAC + SHA256
- RSASSA-PKCS1-v1_5 + SHA256
- ECDSA + P-256 + SHA256

> The specs defines many more algorithms for signing. You can find them all in [RFC 7518](https://tools.ietf.org/html/rfc7518#section-3).

### HMAC algorithms
This is probably the most common algorithm for signed JWTs.

Hash-Based Message Authentication Codes (HMACs) are a group of algorithms that provide a way of signing messages by means of a shared key. In the case of HMACs, a cryptographic hash function is used (for instance SHA256). The strength (i.e. how hard it is to forge an HMAC) depends on the hashing algorithm being used.

The main objective in the design of the algorithm was to allow the combination of a key with a message while providing strong guarantees against tampering. Ad-hoc solutions (for example, appending the key to the message and then hashing the result) suffer from mathematical flaws that allow potential attackers to forge the signature. The HMAC algorithm is designed against that.

The algorithm per-se is quite simple (JavaScript pseudo-code with Node.js extensions):

```
// Key: Buffer with key, Message: Buffer with message
function hmacSha256(key, message) {
    // The algorithm requires the key to be of the same length as the
    // "block-size" of the hashing algorithm (SHA256 = 64-byte blocks).
    // Extension is performed by appending zeros.
    var fullLengthKey = extendOrTruncateKey(key);

    var outterKeyPad = 0x5c; // A constant defined by the spec.
    var innerKeyPad = 0x36; // Another constant defined by the spec.

    var outterKey = new Buffer(fullLengthKey.length);
    var innerKey = new Buffer(fullLengthKey.length);
    for(var i = 0; i < fullLengthKey.length; ++i) {
        outterKey[i] = outterKeyPad ^ fullLengthKey[i];
        innerKey[i] = innerKeyPad ^ fullLengthKey[i];
    }

    // sha256(outterKey + sha256(innerKey, message))
    // (Buffer.concat makes this harder to read)
    return sha256(Buffer.concat([outterKey, sha256(Buffer.concat([innerKey, message]))]));
}
```

HMACs are used with JWTs when you want a simple way for all parties to create and validate JWTs. Any party knowing the key can create new JWTs. In other words, with shared keys, it is possible for party to impersonate another one: HMAC JWTs do not provide guarantees with regards to the creator of the JWT. Anyone knowing the key can create one. For certain use cases, this is too permissive. This is where asymmetric algorithms come into play.

## RSA and ECDSA algorithms
Both RSA and ECDSA are asymmetric encryption and digital signature algorithms. What asymmetric algorithms bring to the table is the possibility of verifying or decrypting a message without being able to create a new one. This is key for certain use cases. Picture a big company where data generated by the sales team needs to be verified by the accounting team. If an HMAC were to be used to sign the data, then both the sales team and the accounting team would need to know the same key. This would allow the sales team to sign data and make it pass as if it were from the accounting team. Although this might seem unlikely, especially in the context of a corporation, there are times when the ability to verify the creator of a signature is essential. JWTs signed or encrypted with RSA or ECDSA provide this capability. A party uses its private key to sign a JWT. Receivers in turn use the public key (which must be shared in the same way as an HMAC shared key) of that party to verify the JWT. The receiving parties cannot create new JWTs using the public key of the sender.

Both RSA and ECDSA algorithms are more complex than HMAC. If you are interested in the gritty details, read [RFC 3447](https://tools.ietf.org/html/rfc3447) for RSA encryption, and the original [ECDSA paper](http://cs.ucsb.edu/~koc/ccs130h/notes/ecdsa-cert.pdf).

The main difference between RSA and ECDSA lies in speed and key size. ECDSA requires smaller keys to achieve the same level of security as RSA. This makes it a great choice for small JWTs. RSA, however, is usually faster than ECDSA. As usual, pick the one that best aligns with your requirements.

<include src="asides/Jwt" />

## Conclusion
JWTs are a convenient way of representing authentication and authorization claims for your application. They are easy to parse, human readable and compact. But the killer features are in the JWS and JWE specs. With JWS and JWE all claims can be conveniently signed and encrypted, while remaining compact enough to be part of every API call. Solutions such as session-ids and server-side tokens seem old and cumbersome when compared to the power of JWTs. If you haven't worked with these technologies yet, we strongly recommend you do so in your next project. You won't be disappointed.

<include src="TweetQuote" quoteText="JWTs are a convenient way of representing authentication and authorization claims for your application."/>
