From the course: Web Security: OAuth and OpenID Connect

Validating JWTs

- [Instructor] JSON Web Tokens, or JWTs, or jot tokens, whatever you want to call them, are both incredibly powerful and completely unnecessary with an OAuth. In the last video, I talked about three types of tokens. Refresh tokens are never jots. Access tokens are often jots, but don't have to be. The final type of token, the ID token, specified by open ID connect, must be a jot token. So regardless of where you find them, you must validate them. You can't use an unvalidated token under any circumstances. Now, before you try to validate your tokens, you must be sure to find the signing keys. You should be able to find them in the documentation for your OAuth provider. Every jot token has three parts separated by a period. There's the header, the payload, and the signature. The first portion, or header, tells us the algorithm used to generate the token. We'll need that in a moment. The second portion is the payload, or the data we actually wanted. At this point, you probably want to grab the fields and start using them, but wait, we can't do that. We don't know if the token should be trusted or if it's been modified. After all, if you're granting user access based on the payload data, we need to know that it's right. That brings us to the third and final portion of the token: the signature. The signature is what lets us validate that the token was sent by who we expected and the included data hasn't been modified. Most programming languages have numerous libraries for validating JWTs, so I'll just mention the steps we need. First, we'll need the data, which was signed, this is the payload, we'll need the algorithm the center used, that was the header, and then we need to combine that with the public key from the sender. That's the signing key we had to retrieve from the documentation. Now, once we calculate the new signature, we compare that with the one sent along in the original token, that was that third parameter. If they don't match, we must reject the token immediately. If they do match, that's a good sign, but we may not be done. In the payload itself, you have some name value pairs called claims. These claims could have absolutely anything in them, ranging from information about the user who authenticated, to the authorization server who issued the token, to information about how long you can use the token. While all these claims are entirely optional, there are a few which you should respect if you find them. There's ISS. ISS is the issuer of the token. This will usually be your authorization server. If you find this field present, make sure it's what you expect. Next is sub, or the subject. This is the entity the token is about. This will usually be the end user who authenticated or the system who requested the token. Next, we have the aud, or audience claim. This is the intended audience of the token. This is normally going to be the application which requested the token. If you don't respect this, it's like going to a restaurant and getting your order mixed up. You might get something that's okay and works, or you might get something you're violently allergic to that sends you to the hospital. You must respect the audience. Next up we have IAT, or issued at time. This is a simple unix timestamp that lets you determine how old this token is. It's not used often, but it's available sometimes if you need it. And finally, we have exp, or the expiration claim. This is another timestamp describing when you must stop using this token. Once this token expires, you want to get a new one from the authorization server. This is vitally important because your user's information or access could change, and you don't want to make a decision based on bad or out of date information. While it's easy to validate JWTs, it's also easy to make a mistake in it. So I recommend using a proven library. Check out jwt.io for a list of which libraries support which algorithms to find the one you need.

Contents