 How's it going, everyone? Thanks for checking out this video today. Today, what I'm going to walk you through is an introduction to Passetto tokens. If you're not familiar with them, Passetto stands for platform agnostic security tokens. It's a relatively new standard. I was designed about two years ago as a replacement for JSON web tokens. Now, I'm assuming if you're watching this video that you're probably a web developer or backend developer of some sort who at least has a little bit of interest in web security topics. Maybe you've worked with token authentication before, or maybe you've used JSON web tokens and seen the word Passetto being thrown around. And so throughout this talk, I'm going to explain what Passettos are, how they work, how you can use them, and then also how they're different and better than JSON web tokens. Now, before I get into that, I just want to make a quick amendment to the title of this presentation. So as of right now, the way this presentation reads is an introduction to platform agnostic security tokens tokens, which sounds a little funky. So what we're going to be talking about today is just an introduction to Passetto. Anyways, with that said, let me quickly introduce myself. My name is Randall. It's very nice to meet you. By the way, if you have questions or comments or suggestions or anything like that, please leave a comment down below and I'll be happy to respond to each and everyone that I see. But I'm essentially the chief hacker at Okta. And if you aren't familiar with Okta, we are a web security company. And we just make it really easy to handle things like user registration, user login, password reset, social login, single sign on, anything related to storing user accounts and handling user authentication and authorization. That's sort of what we do as a service. Now, a bit about my background, just so you know where I'm coming from, I've been a developer for approximately 20 years now. Nowadays, I mainly work in Python, JavaScript, and Golang. And that's primarily working on open source developer tools and developer libraries in the security industry. So I work on a lot of security projects and things of that nature. I'm also an author. So I've written a couple books and I write extensively about web security topics on both my personal site, as well as the Okta developer blog, and I'm a builder. So over the last 20 years, I've launched a ton of different projects. A lot of them have been focused on web security. Some of them are API services and other useful tools for programmers. So hopefully that gives you a little bit of information about my background. Now, with all that being said, let's get into the bulk of the reason that you are watching this video today, which is, what are Pasettos and why should I care about them? Now, before we talked about what Pasettos stands for. So platform agnostic security tokens. When you sort of string it together like that, it sounds relatively complex. I mean, what's a security token? Why, why should we care that it's platforming agnostic? All of these things are good questions. And so I realized that Pasettos sounds a little complicated. But behind the scenes, it's extremely simple. The way you should think about a Pasetto is that it's just a blob of JSON data that you want to securely transmit over the internet. That's essentially all it is. Yeah, there's a bunch of technicalities. They can do different things. They have different pieces of functionality in them and stuff like that. But at the end of the day, it's actually a very simple concept. It's really just a blob of JSON data that you want to send over the internet. Now, there is one thing you should remember about Pasettos on the security side, which is that they're always authenticated. So what do I mean by authenticated? Well, essentially what I mean is that they are cryptographically signed. So let's talk about that. So what's a cryptographic signature? Because when I say that they're cryptographically signed, what does that actually mean? Well, imagine, imagine this, I want to write you a letter. So I type up this nice letter on, you know, on my computer, I print it off and at the bottom, I sign my name. Then I put that letter in an envelope and I put your address on the front and I mail it to your house. Well, when you receive that letter, and you start reading that letter, you might be suspicious of what's written on it, right? Because you're, you know, it says from Randall on the front of the envelope, but all that's typed. And then you're reading the message itself, but it's also typed up. So you can't see that it has my handwriting on it. But then when you get down to the bottom and you see my signature, you'll then realize, oh, well, okay, I mean, I know who Randall is. I know what his signature looks like. And this is, in fact, my signature. And I trust him. So therefore, because I trust Randall signature, I therefore trust all the other information on this page, even though it wasn't specifically written by him. So if that makes sense to you, that's essentially the same thing that's happening, except with JSON data. Now, what are passettos used for? The simplest way to explain it is that passettos are used for proving that some JSON data can be trusted. That's really the main use case here. So despite all the other things we're going to cover today, this is what their purpose in life is. And the best way to think about it, going back to that cryptographic signature analogy is sort of like a passport. So I live in the US and I have a passport. And when I take my passport to the airport, the, you know, the, the TSA agents, the airport agents, they're going to take a look at that passport, and they're going to see a bunch of data on the passport. They're going to see my name, they're going to see my birthday, my height, my weight, my eye color, all of these attributes about me. And that's essentially what the inside of a passetto is. It's just the JSON data, these attributes about something, right? So the passport data on there is essentially just like some JSON data in a passetto. And then when the agent looks at that passport, they're going to make sure that it's a valid US passport. And how do they do that? Well, the first thing they do is they actually look at the passport, and they say, okay, well, I know who the US government is. And so therefore, I'm going to trust in the US government. And that's the first thing. So they have to know who the person signing this passport is. Secondly, they're going to look at the passport itself for all the watermarks in the pages for like the stamps of approval. And they're going to know what those things look like. That's where the signature comes into play. So the agent is going to take a look at the passport. They're going to make sure it's a valid passport by looking at all those attributes we just said. And then once they believe that this is a valid US passport, they're going to trust all the information it contains. And that's essentially the same thing that happens with POSETTO. So when I create a POSETTO, the only difference between that and a passport is that, you know, a POSETTO can only be used a single time, whereas my passport can be used many, many, many times, right? Like I can go through the airport 50 times, and the agent will always accept my passport. Well, with a POSETTO, I'm only allowed to use it once. And then secondly, POSETTOs can only exist for a very short duration of time, whereas my passport lasts for, I think, you know, maybe 10 years. So POSETTOs can only be used a single time and they have a very short lifespan, but other than that, they're basically just passports that are digitally created. Does that make sense? Good. Moving on. Now, what does a POSETTO look like? Let's talk about this for a few minutes. So this string on the right side of the screen that you see is a POSETTO. And it's very simple. It's just a big string. It's period delimited. So each of these periods in here break up and that's, you know, has a different, you know, breaks up a different segment of the POSETTO and we'll cover what each one of these segments is. But the important thing you need to know about the POSETTO string overall is that it's always going to be base 64 encoded and URL safe. What does that mean? Well, essentially what that means is that this POSETTO is designed to be included in web requests. So you can throw it in a URL query string parameter when you're making a request to a website. You can throw it in the body of an HTTP request. You can use it in any sort of web way and it will be super safe and easy to use in that regard because of the way that it's encoded. Now, the first segment of the POSETTO string, which is delimited by those periods again, is called the version. And the version refers to the version of the POSETTO standard that is currently being used. Now, currently when I'm giving us this presentation today is a, what is it? October 2019. There are currently two versions of the POSETTO specification that exist. And the way the standard works is that technically you are allowed to use the current version of the standard and up to one previous version of the standard. So as of at this point of time today, users could technically use either v1 or v2 of the standard. If v3 comes out a year from now, then users would only be allowed to use v2 or v3, but no longer v1. Anyways, the version string basically just tells you what version of POSETTO is being used with this token. The second segment of the POSETTO is called the PURPOSE. Now, the purpose is essentially going to describe what type of POSETTO this is. There are really only two types of POSETTOs which you're going to talk about in a few minutes here. There's public and there's local and each one has a different purpose and works with a different security model. So we'll talk about that in a few minutes. The third segment of the POSETTO is called the payload. And this is the part most people care about. The payload is essentially just that blob of JSON data that's been encoded and potentially cryptographic or and potentially encrypted as well as cryptographically signed. And so this is just an encoded form of that JSON data that you're trying to securely transmit over the internet. Then the fourth and optional segment of the POSETTO is called the FOOTER. So the FOOTER doesn't always exist, but if it does, it's a cryptographically signed JSON string that allows you to put extra metadata about the POSETTO in there. This is really useful for handling things like key rotation when they're working with public key cryptography and some other things that we can talk about later on. Now what's inside of a POSETTO? Now we already talked about this earlier. We know that it's just some JSON data, but the JSON data that you actually store inside of a POSETTO are called claims. So every JSON key that you stick in is going to be a claim. So in this POSETTO, we would have three claims. We'd have the ID claim, the email claim, and the permissions claim. And you can stick as much data inside of a POSETTO as you want, and you would just refer to those things as claims. Now one of the cool things about POSETTOs is that not only can you stick whatever data you want inside of them, but there's also a certain amount of reserved claims that all have special functions and purposes. And when you're using a POSETTO developer library, for example in Python or Java or C or anything like that, that library implementation will have all sorts of functionality that uses these reserved claims behind the scenes. So I'll just point out a few of the interesting ones. So the first claim I want to specifically call out is the issuer claim. It's called ISS. And if this claim is in use, then that JSON data in the payload you just saw would actually have a claim called ISS embedded inside of it. And this basically allows you to see who created the token. So for example, if you're building an API service and your API runs at api.example.com, then maybe the issuer for this token would be api.example.com. It lets you figure out who created this token. Another claim I would like to call out is the expiration claim, which is represented as exp inside of the JSON payload. And this claim essentially lets you control when this token expires. Now, I sort of mentioned before that one of the unique things about POSETTO is that they must live for only a very short period of time. And so this claim allows you to decide how long they should live. For example, if it was exactly noon right now, and I created the POSETTO and the expiration time was 12 01 PM, then there would only be a single minute that this POSETTO would remain valid. If I were to receive this POSETTO after that time, then I would no longer have a valid POSETTO. Another claim which is sort of interesting is the IAT, also known as the issued-at claim. And this allows you to tell when the token was created. So you can see when it was created, when it expires, how long it's been valid for, things like that. And there's a bunch of these other reserve claims as well. As a matter of fact, this table was pulled directly from the POSETTO RFC specification. You can look all this up online, super easy to find. And in general, what you should know about these things is that when you're building an actual web application or backend application using a POSETTO developer library, it will automatically have some methods and high-level stuff that you can run to get all these pieces of functionality built in. So next up, let's talk about the different types of POSETTO. So what are the different types that are out there? Well, the first type of POSETTO is called a local POSETTO. These are sometimes referred to as symmetric or shared key POSETTOs, because that is the type of cryptography that they use. They work off symmetric cryptography, also shared key cryptography, those are just synonyms for one another. And we'll talk about that more in a minute. One of the things you should know about local POSETTOs is that they are always encrypted. So if an attacker gets a hold of one of your local POSETTOs, but they don't have the necessary password or key to decrypt it, then they won't be able to see any of the JSON data that you've put inside of the POSETTO. Also, local POSETTOs just as an FYI, they're really simple. So these are sort of the simplest and the most commonly used types of POSETTO. If you're familiar with JSON web tokens, this might sound very similar to like this unencrypted JSON web token. And we'll also talk about that later, but the same sort of concept. So next, there's public POSETTO. Now, public POSETTOs are also referred to as asymmetric or public key POSETTOs because that's the type of cryptography they use. And public POSETTOs are never encrypted. They are always signed. Both of these types of POSETTOs are always going to be signed. So they'll always be able to validate who created them and things like that, of course. But public POSETTOs are never encrypted. So one thing you have to keep in mind is that when you're working with a public POSETTO, any of the JSON data that you store inside of it is could always potentially be public information. So if an attacker gets a copy of your POSETTO, they will in fact be able to see whatever data is stored inside of it. So if one of the requirements of the application you're building is that you need to make sure that JSON data you're transmitting is encrypted, then you're going to need to use the local POSETTO. So keep that in mind. And finally, public POSETTOs, because they work based on public key cryptography, they are just by their very nature slightly more complicated than their local counterparts. But we'll talk about that in a little bit as well. So first off, how do local POSETTOs work? Well, the way local POSETTOs work is like so. You have some JSON data that you want to securely transmit. And then you have a secret key. Now the secret key is basically going to be a long, randomly generated string. And by combining those two things together, with a developer library, POSETTO developer library, you're going to be able to create a local POSETTO, which will look something like this. Notice that the purpose of this POSETTO is set to local. That's how you can tell what type of POSETTO you're working with. Now, if an attacker were to get a hold of this local POSETTO, they wouldn't be able to get any useful information out of it. And that's because again, unless the attacker has that secret key, they won't be able to see any of that JSON data that you've shoved inside of this POSETTO. Now, the real magic of local POSETTOs is happening at the cryptography level right here. And the real magic is that the secret key is needed to both create the POSETTO, which will encrypt the JSON contents, as well as decrypt the POSETTO. So hopefully that makes sense. Now, how do you use the local POSETTOs in a real world application? Well, let's say you're building a website that allows users to purchase videos and then download them. Okay. And so imagine your website has the www.example.com domain, and that domain handles all the logistics of your application, creating the users, letting them purchase videos, stuff like that. And then you have a separate service running at dl.example.com. And this is a very simple download service. And all it allows your users to do is just download files they've already paid for. So this might be one way to architect this application using local POSETTOs. So imagine you have this user and they paid for a video and they want to go download this video, video one dot mp4. Well, the first thing that's going to happen is that when you make that request, the web server, the web server is going to validate the validate your request is going to make sure that this user is logged in, that the user has permissions to download this video and all that good stuff that they've already purchased it, etc. Then the local web server is going to generate a POSETTO and then redirect the user to the download service so that they can download this file. But before we can move on, we need to understand some back in infrastructure stuff in on both of these servers, the same secret key is going to need to exist. So we mentioned before the local POSETTOs in order to create one or decrypt one, you need the same secret key. So what that means is that because both of these services are going to be consuming and creating and these POSETTO, they're both going to need to have the exact same secret key on these servers. And that secret key is going to need to be kept an actual secret. So that means you wouldn't check this secret key into GitHub, you might have it stored in environment variables or in like a vault type type service. So it remains a safe credential. Now, assuming you have the secret key set up properly, what's going to happen is the web server, once it validates a request is going to generate a POSETTO for the user. And it might look something like this. In this case, this POSETTO has a couple pieces of information, it has a purchase ID, and it has an array of permissions in the claims. And these permissions are basically stating that this user is able to download these particular videos because those are the ones they paid for. Now, what happens at this point is the website is going to redirect that user in the browser over to the download service. And it's going to tack on a couple query string parameters onto that request. The first parameter is going to tack on is this token parameter. And that token parameter is just going to be this POSETTO right here in the query string parameters. It's also going to tack on this file parameter. And this file parameter is just going to let the download service know what file it is that the user wants to download. In this case, video one dot mp4. Now, the download service is going to receive this request. And it's going to parse the URL parameters, those token and file variables out of the URL. It's then going to use the secret key here to decrypt this token. It's then going to verify that this purchase ID is accurate, and it's going to verify that the user has the permissions required in here to download this video file. And then finally, assuming all that's good is going to let the user download the file. So as you can see, this is a really nice use case showing off how local POSETTO can be used in a real world application. Now let's talk about public POSETTOs. How do they work? Well, a public POSETTO, again, starts with just some JSON data. Now, in this scenario, when you create a public POSETTO, you instead of having just the single secret key, like a password to create and decrypt the POSETTO, you're actually going to have two keys that you need to worry about. The first key is going to be called a private key, which is a long, randomly generated string. And the private key is something that you will never share with anyone else. So only you the creator of the POSETTO will ever have access to this private key. Secondly, you're going to have a public key. And the public key is this key that you can keep as the creator of the POSETTO. And you can also give to anyone else in the world. And anyone who has the public key, essentially what you're doing is you're giving them information about who you are. So imagine that, like, I meet you when I say, Hey, I'm randomly shake your hand and you recognize me from that point forward. That's essentially the same thing as me giving you a copy of my public key. Now, the way you generate a public POSETTO is by combining those the JSON data and the private key together. And by doing that, using one of the POSETTO developer libraries, you're essentially using public key cryptography to create this POSETTO. And notice again that the purpose segment of this POSETTO is saying public because again, this is a public POSETTO. And that's how you can identify it as such. Now, if an attacker were to get a hold of this public POSETTO, just keep in mind that the attacker will be able to see any JSON data that belongs inside of the POSETTO. So again, a rule of thumb is don't create public POSETTOs and put data inside of them that you aren't comfortable with that data being public anyways. Alright, so just a general rule of them. Now the magic of public POSETTOs is all based on cryptography as well. And that's just the way asymmetric cryptography works. The private key is going to be needed to create the POSETTO and the public key is what's going to be needed to validate the POSETTO. All right. Now, how would you use this in the real world? Let's let's look at a very realistic example. And hopefully this sounds familiar to you. And if not, I will explain why at the end of this slide. Now, let's say you have a website and that website handles everything in your application except for user authentication, user authorization, and basically just logging users in. So let's say you have a user and they talk to the website and say I would like to log in please. So you click the login button on this website and that website will do is they'll say well, I don't handle any of that. I'm going to redirect you to the authorization server I have that will handle all of these things. So now the user is redirected in a browser to this authorization server to log in. This is very similar by the way to like Google login. When you go to Google and you hit login and redirects you to accounts.google.com where you then log in to your account. Now, when this authorization server receives a request, what it's going to do is first of all, it's going to authenticate the user. It's going to ask them what's your email, what's your password, what's your you know, two factor SMS code, things like that. But after all that's done, the authorization server is going to generate a passetto for this user and then redirect the user back to the website they were trying to get to in the first place. Now before you can explain how that works, we need to first talk about some infrastructure security here. So because this authorization server is going to be creating a passetto, that means this authorization server is going to need to have its own private and public key pair that it has created. And because the website is going to be receiving this passetto, it's going to need to have a copy of the authorization server's public key. So before these two, these two parties can work together, this key negotiation must have already been completed. Hopefully that makes sense. Now what's going to happen is once the user's been authenticated, the authorization server will generate a passetto. This is just an example, but, you know, maybe a passetto will be generated that contains a piece of information that you don't mind being public like, for example, a session identifier. In this case, I'm using user ID just as an example, but in the real world, you probably have something a little more opaque. So you have this passetto that's generated, and then you're going to redirect the user from the authorization server back to the website with this passetto token in a query string parameter, much like you saw before. Now the website is going to parse that token out of the URL when it receives this request. It's then going to validate this token using the public key that it has. That way we'll be able to see that hey, this token is valid. It was generated by the authorization server that I already trust and that everything is good. And then finally, the website is going to create a secure server side session to keep this user logged in. So there'll be a cookie generated, the user will be authenticated, they'll have a session set up. And then from this point forward, the user is now logged into this website, and they can, you know, go about their normal business. Now, because this flow looks sort of familiar to a lot of you, it looks like a social login flow, something that happens with Google or Facebook or Twitter or anything like that. It that's because it is this is essentially what the open ID connect flow is. As a matter of fact, passettos are hopefully going to be introduced into open ID connect in a future version of the specification. And that would sort of be a nice thing. Now, you might be wondering, okay, well, passettos seem very much like JSON web tokens. And that would be a very astute observation. And the best way I like to describe this is that passettos were created as I believe I mentioned earlier as a more secure alternative to JSON web tokens as a simpler and more secure alternative to JSON web tokens. And one of the high level reasons why passettos were created is that essentially, JSON web token is part of a family of specifications known as the Jose family of specifications. And these specifications include not only JSON web tokens, but things like JSON web signatures, JSON web encryption, JSON web keys, things like that. And all of these standards together allow you to have a lot of useful functionality in modern web applications. Unfortunately, however, the JSON web token and Jose family of specifications in general has a lot of practical issues. So there's a lot of great ideas in the standards, but there's also a lot of poor ideas. And so the creator of passettos essentially decided, hey, I really like the idea of JSON web tokens, but the implementation not so much. So what he decided to do was take the good parts and distill them down into a separate specification that was designed to be easier and more secure to use. Now, with that being said, let's let's go into some more of the details. What's wrong with JSON web tokens? Well, first of all, they're widely misused. I have a very popular YouTube talk you can go look up called why JSON web tokens suck, which goes into depth on how JSON web tokens are misused. But the short of it is that people misuse JSON web tokens by reusing them many, many times and giving them long expirations. And then they're also misused in the sense that the JSON web encryption spec doesn't allow for secure cryptographic operations and some other things which we'll talk about in a second. So this is the first problem with JSON web tokens is that people use them incorrectly. The second problem with JSON web tokens is built into the spec itself. And that is essentially that the JSON web token spec forces developer library implementations to process the thing called the Alg header. And this allows you to have token forgery issues. Now, if you're familiar JSON web tokens at all, you've probably heard of massive JSON web token library compromises and exploits because of this issue in the past. Today, while a lot of those things have been resolved, technically, a lot of these libraries are not spec compliant because they aren't complying with the way the spec was designed and how it was essentially written to allow people to have these token forgery issues. So the spec is just not super clear here. And it sets sort of a bad precedent for web security. Thirdly, JSON web tokens and JSON web encryption in general and in particular allows for some really poor cryptography choices. So for example, RSA with PKCS is vulnerable to padding oracle attacks. And this is a really bad type of attack where you are essentially opening yourself up to a lot of serious security issues. As a matter of fact, RSA in general should not really be used anymore. RSA with OAP padding, this is basically like one of the best options that JWE technically allows for. But cryptographers have been recommending that people have been that people migrate off of the RSA crypto system for several years now. So even though this is technically usable today, it's not really advised by any modern cryptographer because RSA is just sort of a very confusing nightmare of a specification. Next, using ellipticurve Diffie-Hellman is fine, but using the weirstrost curves is actually a poor curve choice. And this introduces the risk of invalid curve attacks that allow attackers to steal your secret keys. And this can be a really big problem, of course, if you're using a token and relying on the secrecy of a secret key for your security model. And finally, one of the other problems with JWE is it allows the use of AES GCM, which is just the wrong type of cryptography in general. There's basically two different types of common web cryptography. There is symmetric and asymmetric. And essentially, the JWE spec is using symmetric encryption when asymmetric is needed. So there's just some some really big basic core cryptography issues with JWE as a whole. And that's why cryptographers tend to get really angry when they see people using JSON web tokens. So with that said, my call to action for all of you watching this video is go and give POSETTO is a try. If you go to the official website for POSETTO technology, it is POSETTO.io. You will be able to read the RFC and learn more about the specification. Find all of the great developer libraries there. I believe at this point in time there are 16 developer libraries across a number of different programming languages to use. You can also find articles and videos and all sorts of things like that. I would also just say that POSETTO is an open standard that's being developed. There's currently a lot of people working on it. So go and get involved if you are interested in this at all. And essentially the next time you're going to be using JSON web tokens in a project, just think about it and see if you might want to substitute those JSON web tokens for POSETTO as a simpler and more secure alternative. So with that being said, thank you for your time. It was great to be here. If you'd like to learn some more about this stuff, feel free to check out my personal site, rdex.com. You can also check out developer.octa.com to learn more about things there. And unfortunately the Twitter links aren't working, but you can always follow me on Twitter. I'll drop those links down below in the description. And thank you very much for the time. Take it easy.