Latest / The Laravel Podcast / Sanctum & Passport, with Taylor Otwell

Transcript

Sanctum & Passport, with Taylor Otwell · The Laravel Podcast

• Matt Stauffer: Hey, and welcome back to Laravel Podcast, Season five, where every single episode is about a single package, except when we're talking to Taylor Otwell, in which case we might get multiple packages like we're doing today. Today, we're going to cover the API login, authentication systems, Passport and Sanctum. So we're first getting started with Passport and talk about the history of that, and then Sanctum, which didn't replace it, but is a new way of looking at it. We'll go there. For starters though, Taylor, say hey to the people real quick. I know they all know who you are, but just give you a chance to say hi before I start asking you question. Taylor Otwell: Hey everybody, Taylor Otwell. Matt Stauffer: Taylor Otwell in the beautiful new house with the amazing decorations that makes my, what are these called? My Funko Pops jealous a little bit. Matt Stauffer: All right. So, today let's get started with Passport. We talked a little bit beforehand and just said, "Hey, you know what, Passport, what came first?" So, you know the things we're going to be talking about. What is Passport and, what are some cool ways people use, and what are some things they should know about it. And then we're going to do the same thing for Sanctum. Do you want to get started just talking about Passport or do you want to get started by talking about the difference between the two, in case anybody doesn't know? Taylor Otwell: Yeah, I think it makes sense to get started with Passport and we'll go chronologically. Matt Stauffer: Okay. Taylor Otwell: Because Sanctom's existence is, because of our experience with Passport. Matt Stauffer: All right. So, if somebody's never heard of Passport before. What is Passport at its core? What's the elevator pitch. Taylor Otwell: Passport was written to make it easy to do OAuth 2 in your Laravel applications. And I'm going back into GitHub here. It looks like it was released, the first tag was August 16th, 2016. Matt Stauffer: Wow. Taylor Otwell: And so, there was packages to do a OAuth in PHP applications in general already, and Passport depended on those. The league of extraordinary PHP packages, I think the GitHub organization is called. They have an OAuth 2 server. Passport depends on that, and wraps that up in a convenient, accessible way specifically for Laravel applications. Matt Stauffer: Yeah. And if anybody's ever created their own, I'm sure we've talked about this in previous seasons, but if anyone's ever even using those packages needed to create your own basically, OAuth 2 server, there's a lot involved in knowing which grants you want and how to configure it. So Passport takes a lot of that knowledge off the table for you to have to know. Matt Stauffer: And you just like, "Hey, just set it up. Here's the defaults. Here's some really good defaults, but still maintaining most of the same level of configurability that the original package had." Taylor Otwell: Right. Matt Stauffer: So, if we were to talk about that, if someone were to, at that point, now we're talking before Sanctum existed. At that point, with someone who were to have wanted to install Passport, what were the primary goals that they were trying to accomplish in order to, that they were going to use this in order to accomplish. Taylor Otwell: I think there's a few use cases that people are using Passport for. And we were talking before we started recording, that actually it is the most installed Laravel package statistically, not counting any packages that are included in the Laravel skeleton, like Tinker, or now Sanctum, because those stats are inflated by every Laravel installed. Taylor Otwell: But I think people are installing it, because one, they might want to issue API tokens to existing customers. They may want to authorize mobile applications. I know people use it for that. So they have their back-end Laravel application and then they set up Passport. And then from their mobile app, they go through some sort of OAuth authorization flow against their Laravel application and Passport issues, their mobile application, a token that they then use to authenticate. You can even use OAuth to authenticate, like cron commands on other machines or CLI tools. So you can do all kinds of different things with it. Passport even adds on the ability to create what we call a personal access token, which will tie into Sanctum later where it's basically, if you've ever used GitHub and you go out there and you can create a little API token just manually, and some menu on the GitHub UI, they refer to those as personal access tokens. Taylor Otwell: And you can do that in Passport as well. So a customer might log into your application, go to some API setting screen, hit create API token, and then you use Passport's personal access token feature to issue that API token. So there's a variety of use cases, but I think that's the main ones that people are doing. Matt Stauffer: Yeah. And if anyone's not familiar with the OAuth 2, the more traditional flow, it's if you've ever set up a website that is going to integrate into some other website. Let's say you are using some tool that integrates to your GitHub. And so, you press this button on the other tool and it sends you over to a page on GitHub that says, do you want to give this other tool permission to access A, B and C of your GitHub profile? Matt Stauffer: And it's got a little logo of that thing that say, yes, it sends it back over, and now those two are integrated. That's what the most common full OAuth flow looks like. And then the same thing is true like Taylor was saying for a mobile app, where if you say, login with X, Y, Z and then it takes you over to Facebook and Facebook says, do you want to give access to this thing who you're... That's what the full OAuth flow tends to look like. Whereas the personal access token Taylor's talking about, is much, much more the simpler one. It's just like, "Hey, I just need a long hashed string that proves who I am without having to go through this whole massive web flow that also took a lot of work for somebody to build." Matt Stauffer: And one of the things that Passport does that makes this whole system a lot better, is it allows you to build that user interface much, much, much more simply than if you had to do it on your own using the existing tools. So installing Passport, obviously we can look at the docs, but are there any aspects of installing Passport or any dependencies that are worth calling out while we're in the podcast or is it all pretty straightforward? Taylor Otwell: It's pretty straightforward. You just install it using Composer, and then running a full Oauth 2 server requires Passport to create four or five database tables actually for access tokens, refresh tokens, OAuth clients, personal access tokens. So it's got more database tables than most other packages would require, but other than that, it's pretty straightforward to install. Matt Stauffer: And it generates some local key files as well, right? Taylor Otwell: Yeah, that's true. It does generate two encryption key type files, and you have to ship those into production via environment variables or through actually putting the files on the remote servers or something like that. Typically, I do it through environment variables. Matt Stauffer: Okay. So yes, if you've ever done Passport Install, just a note that one of the things Passport Install does, is generate those, but those are usually not the same ones you want to use for your production. So if you go to production with Passport, and all of a sudden it's not working, that's the first thing to check is, have I run migrations, and have I installed those keys on the production server? So obviously you mentioned there's a ton of different things that people can do with Passport. And normally what I'd be asking you is, are there any lesser used features or cool things you seen people do with it? Matt Stauffer: I assume that people can do all sorts of incredible things with Passport because it's so robust, but it's also very complicated. No, it's not. I don't want to say it's complicated, but Oauth 2 is complicated. There's all the different flows and the grants and all this kind of stuff. Have you been in a place recently, and I know that we haven't talked about Sanctum yet, where you go, oh man, that's a really impressive and incredible usage of Passport where that's the only tool you could have used this for that's outside of the norm of what we've already described. Or most of the time, if you're seeing people using Passport, it's like, yes, that is what we traditionally use OAuth for. Taylor Otwell: I mean, it sounds bad, but honestly I think too many people use Passport. I think most people that are using it, could get away with something simpler. And that bothered me for a long time, which will lead us into our Sanctum discussion. But if you actually are doing the whole flow where you get redirected to your Passport application and you authorized the user for certain scopes, and then you get redirected back to some other application, to me, that is the classic use case that, yep, you're going to have to use Passport to do that if you want that functionality. Taylor Otwell: If you're trying to do something else, like authenticate, just issue API tokens in general, or even authenticating a mobile application or an SPA application, that is something that I do not think you need Passport for anymore. It used to be your only option, but you just don't need, like you were saying, Oauth 2 is inherently complex. I mean, it was made to be simpler than Oauth 1, but it's still quite a bit more complex than is actually required to do just basic API authentication or authenticating some react front end. Taylor Otwell: And I don't actually think people realize that it doesn't have to be so complicated to do those task. They very much have it in their head that, oh, I need to authenticate an API. So I guess I need this big OAuth package, and which is not necessarily the case. Matt Stauffer: Well, I mean, I think that's a perfect transition moment. We don't need to talk about development roadmap, because I know its primary goal is just to do what it does right now. Oauth 2 isn't changing anytime in the near future. So why don't we transition and talk about Sanctum? Where did Sanctum come from, and talk a little bit about what you were sharing about how Sanctum does some things that previously you had to do in Passport, but maybe it was overly complicated. Taylor Otwell: Yeah. So Sanctum comes out of a lot of feedback and seeing a lot of confusion and frustration with people trying to use Passport, not knowing what grants to pick, what OAuth grants to use to authenticate their application. Taylor Otwell: It feeling really heavy handed for something like just issuing an API token that you need four or five database tables. And so, I would say the early history of Sanctum actually comes out of my work on Spark back in 2016 or 2017, where I built this little API layer where you could call your backend from your front end, and it all just worked seamlessly and you didn't need to do any weird OAuth flow or anything. And it just got me thinking like, someday I want to extract out this simplified API setup into a package. And eventually I did that with Laravel Sanctum to where the primary use case is to solve the problem of issuing API tokens to third party users. If your servers offers an API, like the Forge API or Vapor or whatever, and also authenticating SPAs and mobile applications, because a lot of people are doing that these days. Taylor Otwell: And like I said, that so many people had it in their head that, oh, if I'm doing that, I need OAuth 2 or maybe even I need JWT, which is another common thing like, I can't authenticate with an API, unless I'm using JWT. That was another misconception people had in their head. And that leads you to just a whole other road of complexities, basically. Matt Stauffer: Yeah. Taylor Otwell: So I built Sanctum as like, no, it has one database table to store API tokens for users. You can issue them to users using a simple API, really clean developer experience where your user model has API tokens trait. And you just hit, create token method on the user, to create a token for that user. And it has similar scope functionality to OAuth, where you can pass an array of abilities that this token has. Taylor Otwell: And then once someone authenticates with that token, you can see if they have that ability. For example, in a Forge context, does this token have permission to create a server, to delete a server? Things like that. And then the flow is very similar for a mobile application. If you're building a mobile application, you would set up a login screen on the mobile application, which calls your Laravel application. And all that does, is call create token if the credentials are valid and passes it back to the mobile application. And then in the UI, you can just list the tokens for that user and the user can, if you want, let them delete them, or whatever. So it really streamlined the whole thing, I think, for the most common use cases of what Passport was being used for and made it so much more understandable, because you don't have to go through this whole process of, which grant do I need to use? Taylor Otwell: Am I using it correctly? Because if you don't use the grant correctly, maybe your application's insecure, you can literally build it insecurely if you pick the wrong grant in Oauth 2, and it's just so much faster to get started and more lightweight. So it's actually, I wanted it to be the default choice so much, that I just included it in Laravel. So, modern releases of Laravel 8 just includes Sanctum by default. And the API routes file is already set up to authenticate using Sanctum. So it's pretty much all ready to go. Matt Stauffer: Mm-hmm (affirmative). So, we have Sanctum, and Sanctum is much simpler to use, much simpler to install, because it comes out of the box thing that is providing a lot of the same features that Passport was previously, but just rather than, oh, we have this existing schema, this concept called Oauth 2, that then somebody else has built a PHP server for that we're going to put a layer on top of. It was Taylor saying, Hey, what is it going to be from scratch? What do I think should be the experience like, and how can I make this as simple as possible having already done it practically in real applications? So it's not just super ideal. It's something you'd actually tested out. Taylor Otwell: Right. Matt Stauffer: Sanctum sounds like the dream. And to me it actually is a dream. But I'm curious, now that we have Sanctum, if somebody's making a mobile app they need to authenticate, they're going to use Sanctum. Matt Stauffer: If somebody can do an SPA, they should use Sanctum. Somebody's going to create tokens, and if anybody's not familiar, go to Forge or go to GitHub or something like that and go, just say, create a new token for those tokens that you're going to use. It's going to be, again, just a long string. Sometimes you can give it nickname or not, and that token is just going to be what you use to put into some application that authenticates against GitHub, or some application that authenticates against Forge or whatever. That's all we're talking about with the personal tokens. So if somebody needs to do any of those things, they reach for Sanctum, which is already built into Laravel, out of the box. At what point should they actually still consider Passport, now that Sanctum exists? Taylor Otwell: I don't know. I can't say. That's the question I wish I had the answer for, I feel like, because like I said, Passport is such a popular package. So I don't know if that is because there were so many years where it was the only option. And so many people are still using it and it's expensive to migrate their code away from it and make those changes, and just risk even with maybe not much benefit on the business side. Or are people still reaching for it a lot in new applications, and if they are, I'm not sure why. That's something I would like to figure out, I think, through some poll or information gathering. But in the Passport docs, we actually have right at the top introduction section, we have a little subsection that just says, Passport or Sanctum, question mark. Matt Stauffer: Oh, nice. Taylor Otwell: And to try to make people think before they go down the OAuth 2 road, and it basically says, before getting started, are you sure you actually need to use Laravel Passport? Which I think it feels like a weird thing to do in your own package, to almost encourage people not to use it, but I just think, we want people's experience to be as good as it can be and I don't want them to use something that they don't actually need. And so, it basically just says like, if you're trying to create a single page application or a mobile app, or you just want to issue some API tokens, you should use Laravel Sanctum. If you are absolutely sure that you need a full OAuth 2 spec package, because you're going to be doing that kind of thing, that whole login flow and exchanging credentials like that, then sure, Passport is, that's your thing, that's what you need to use. Matt Stauffer: Yeah. Yeah. And the main use case I can think of, which is almost none of the clients I've ever worked with is, if you have a primary service, let's say it's a GitHub or Facebook or something like that, that you want not just to give maybe higher tech people to be able to say, go into the service and create a token that you can give somewhere else. But instead, you want maybe more end users to be able to authenticate against, and say, yes, give it permission to do this. If you're saying like, I'm going to play this video game and the video game wants to authenticate against my Facebook, and the Facebook should be deciding how much information are they giving to the video game? That I feel like, is the space for the more traditional OAuth flow. Taylor Otwell: Yes. Matt Stauffer: But that's it. It's two full web applications that need to be able to share that authentication and layer of certain amounts of information, where you don't want the end user to have to be able to go create a token. So it's basically not developer facing. Two web apps, not developer facing. Taylor Otwell: And like you said, the only reason you're doing it like that, is more just ergonomics. It's not because it's required. In that video game example, you could have had the user go copy a token, you know what I mean? From somewhere else, and paste it into some text box and say, okay, here's my token and here's the permissions I give it. The only reason we don't do that is just, it's not, like you said, non-developer friendly. Taylor Otwell: And it was interesting. I actually read an article from one of the OAuth 2 spec authors where he basically says that, people have this mystical view of OAuth 2, when really, you could have just had a text box and a form that generates an API token and then the user pasted it. That's actually not any less secure than OAuth 2. It's just not very ergonomic for the end user. Matt Stauffer: Yeah. That's a helpful thing. Yeah. Because I do think that a lot of people who are using Passport probably have the idea that it's more complicated and it's more a named standard. Therefore, Passport must be the more secure option. I think it's really helpful to hear you saying, Passport is no more secure than Sanctum. There's only one circumstance in which we're talking about that it can do something Sanctum can't, and the only reason you do that circumstance, is for user ergonomics. Not because Sanctum's actually any less secure in that particular circumstance. Taylor Otwell: Right. Yeah. Matt Stauffer: Okay. That's cool. So now that we're talking about Sanctum, are there any lesser used features or things that you think that people don't know about what Sanctum can do that you want to share about, or is it all pretty out there in the open? Taylor Otwell: Well, I think the cool thing about Sanctum actually that people may not know, is the way that it lets you consume your API, like your backend Sanctum authenticated API from your, let's pretend you have an inertia front end maybe, so that you have a view template and you're going to use either the node-fetch or Axios or some HTTP client to consume your own backend API to get some data on the client after the page is already loaded. Taylor Otwell: To do that, the cool thing about Sanctum is, you would normally expect like, oh, well, if I'm going to call my own backend API it from here, I need to pass an API token so it'll be authenticated. But the cool thing with Sanctum is, you actually don't. And the magic sauce behind that, is that when you're using Sanctum, you can configure it. And this is how it's configured by default as well, to first check is there a valid session cookie in the request? And if there is, let's just use that authenticated session, and then if there's not, we'll fall back to an API token. So, what's cool is, in a web application context or maybe an inertia app, or whatever, a live wire app, it doesn't really matter, when you make that request to that backend API, the browser's automatically passing all your cookies with it to that domain. Taylor Otwell: So it's going to see you as authenticated. And Sanctum's going to go ahead and authenticate you, because it checks first for the cookie. "Yep. I have a cookie, so I'll just authenticate the user using this", and you're good to go. And that makes it so much easier to consume your own API from your front. And if you're trying to do this thing where you want your front end to consume the same API that your customers consume, and there's just one source of truth for your web application through this API, is so easy to consume it. And we actually have a section in the docs. If you go out to the Sanctum docs up at the table of contents, you can click on the, yeah, it's under the API or the SPA, I'm sorry, SPA authentication section. And it talks about how this works and how to do this, but I think it's a really cool feature of Sanctum that makes it so much easier to do this kind of thing and to consume your own API. Matt Stauffer: Yeah, absolutely. Because otherwise, what you'd end up having to do, is basically authenticate, send a token up to the thing that's the front ends holding that token, and then the token is being sent in. Which we've all done it, but it's work that you don't have to do, because it's literally being authenticated because that user is already logged in, in the SBA. Taylor Otwell: Yeah, exactly. Matt Stauffer: That's cool. That's great. Do you have any development roadmap plans? Is it relatively well settled in terms of what it's doing right now? Or is there anything you're planning to do with it in the future? Taylor Otwell: I think the most recent thing we added that will be a major update, is the ability to set tokens to expire. So in the first release of Sanctum, and this is the same in GitHub personal access tokens as well. Taylor Otwell: Once you create a token, it doesn't really expire until you manually delete it from the application UI, but in the upcoming release, you can actually set an expiration date, if you wanted tokens to expire after one year or whatever. So other than that though, it's been a really stable package and there's not really... We haven't even had a lot of requests for more features, because it's just one of those packages that has a specific domain and just solves that domain, I think really well. And so I think it feels pretty good. Matt Stauffer: I love it. Okay. I know that you are less likely than other package authors to request any help or support, but just, I'll ask anyway, is there any help or support you feel you need in the future development of Sanctum? Taylor Otwell: I always feel like, if you're trying to use Sanctum and you find it confusing or you think, "Hey, this isn't as easy as Taylor said it was going to be", let us know so that we can improve the documentation. Or if you could even pull request the documentation, to me, that's always really helpful, because I can't see it through a new developer's eyes anymore, because I wrote the package. I'm deep into it. So if you're trying to use it and you say, "Hey, this isn't what I was promised it to be", make a PR to the documentation. Taylor Otwell: The wording doesn't have to be perfect, but if you can get us started with a rough draft of explaining what you found confusing, I can go into the PR and massage out the wording a little bit and get it integrated. So anyway, that's what I would say in terms of help. Matt Stauffer: Okay. I love that. I think we've covered the basics for everything I wanted to ask in terms of Passport and Sanctum. But is there anything you want to cover that we haven't talked about yet today? Taylor Otwell: No, I don't think so. Just that, if you're building a new application or maybe you're building a new mobile app, take a look at Sanctum, and don't assume you need a huge complicated setup to get that going. Matt Stauffer: That's good. Yeah. TLDR is Sanctum first, unless you can really be sure you need Passport, but Passport's still good, right? Taylor Otwell: For sure. Matt Stauffer: I love it. Taylor Otwell: For sure. Yeah. Matt Stauffer: Well Taylor, thank you as always for building these tools. Thank you so much for joining me today and we'll see you next time, man. Taylor Otwell: All right. Thanks.