How to add user authentication to a Django website or API. Topics include sessions, tokens, JWTs, Social/OAuth, and more.
Carlton Gibson 0:06
Hi, and welcome to another episode of Django Chat. I'm Carlton Gibson. I'm here again with Will Vincent. Hi, Carlton. Hi, Will.
Will Vincent 0:12
We're gonna talk about authentication this week. Well, what's authentication? I'm glad you asked. So authentication is how you sign up and login to a website. It's commonly confused with authorization, which is permissions. So for example, if you know some people have access to some parts of the site, and others don't to others, that's authorization. authentication is just how do you log in and say, Yes, I'm a user of this site. And Django has a lot of options here, a lot of built in a lot of third parties. So I think there's a lot to unpack about how to do it. But almost every website, you're going to need authentication. So maybe we'll start so I have an entire 40 minute Django con talk on authentication within Django rest framework, because it can be confusing, so we'll link to that. And I'll try not to repeat all those points, but a distinction is between Django Django rest framework. So Django itself web framework uses sessions and cookies. So that is where when you first sign into a site, you send your username and password, which creates a session object on the server. And the server sends back a session ID so that Id can be linked. And so that is what's passed back and forth. that's built into Django itself. That's the predominant pattern with websites. But as we'll get into with API's, things are a little bit different. But that's what the first thing you should know is sessions and cookies. That's what Django uses. That's what basically every web services, it works. I don't think there's much
Carlton Gibson 1:42
add on that. No, I mean, so the Django has contrib dot auth, which is where you get your basic user model, and you can create a custom user model if you want. Now, we've talked about this on another. On one of the first episodes, I use the bog standard model. Because when I create a new project, I just want to get going my idea. It my thought user profiles, will I use the bugs, the user model that comes with Django. Okay. And then if I need to store additional fields on that, I'll create a profile model with a one to one field. And Django does have this ability to create a custom user model. And they, they kind of recommend that you do, because if you want to customize it later on, it's quite a difficult thing to do. Now, over the years, I've come around to the confusion, not just use it and stick with it. But that's my, my take.
Will Vincent 2:31
Yeah, yeah, there's, well, there's, and this is like, the first point of confusion for people is, there's three dominant patterns for doing this. There's, as you mentioned, using the built in user model and creating a profile model for additional fields, there's, and then there's creating a custom user model, which came in I think Django 1.6, something like that. There you you basically, there's two ways to do it. You can create a copy, basically, extend the built in user model with abstract user or you can actually Track base user, we go a level deeper. And so this is what you do if you want to use a Django user's username, email password, because that was the dominant pattern, whatever 1212 back in the day, and there are ways to hack around that. But most sites these days, just want email and password. And so this is some of the reasons why you might fiddle around with this. But again, I think I've come around to your point of view, I mean, I use custom user models. But I think it's easy to confuse, you don't want a complicated sign in, you may want to add all sorts of information later when someone has a profile such as age and this and that, but you don't need that when they sign in. So that the user model is only for signing up and logging in. That's it, then you can link everything else to it. Yeah. And the big danger for me with custom user models, and I've seen this I've seen this is that teams create a custom user model. And then they start adding field after field after field and it becomes this. And what you really want is a separate profile model for all of that data, which links to your user model because your user model is for authentication. You Want to keep it nice and small with just a few fields. And for me another benefit of using Django contrib. The author user model is that it stops you doing that is it stops you falling into this trap where you added, you know, like this massive
Carlton Gibson 4:15
life biography field to your login model.
Will Vincent 4:19
So do you do you do something to remove the username part of that, or do you just want to
Carlton Gibson 4:24
Yeah, I actually quite like user names. I'm, I think I'm old and I'm like, get off my lawn. So old car. Yeah, no, you know, I'm nearly in management age. And as my talk in Heidelberg, in Django, con Europe a couple of years ago was all about,
Will Vincent 4:41
but yeah, by the way, that's that's a fantastic talk. That's when I first learned about you and reached out to you about that talk. I sent you an email saying I really resonated with that talk about
Carlton Gibson 4:53
growing old gracefully, and it's about being a programmer as you get older. And so anyway, I recommend that because it's you know, It's a challenge in our industry. But so I've used and still use Django, all auth, which is one of the 30 around this. And what that enables you to do very well is it sets up a custom authentication back end, which enables you to use emails as your login. So one of the reasons perhaps, I think, probably Historically, the main reason that custom user models were brought in was because people wanted email logins, but on Django contrib dot auth. user, the email field is not unique. So you have to enforce that somehow, in order to have a unique field for login and all auth puts all the machinery around that for the custom back end. And when you create a new user, making sure emails are unique, and that they're tied to a user in a unique way, such that you can use logins with email. And so if I want email login, I use OAuth for that, but I still like usernames because quite often you want a display name you want, you know a forum or you know the To see what user is without using their real name, and without using their user ID, which is potentially sensitive. And so I still like usernames.
Will Vincent 6:10
Yeah. I think the other major package is Django registration, which has also been around for quite a while, and it's still being worked on.
Carlton Gibson 6:18
And what Yeah, and what that does give you signup forms, and it handles this confirmation flow. So normally, you want a user signs up, you have to, you get an email, and you have to click the link to verify your URL. Right. So Django registration gives you all of that, and it's good. It's by James Bennett, who's big, big, longtime contributor to Django.
Will Vincent 6:36
Yeah, I remember the DSF board edge, if you've used other frameworks, other frameworks, sometimes just they give you the like the signup page. So Django does not, which is what partly why these things come about. Django does give you the login and logout forms, but you have to do the signup page yourself. So that involves views, URLs, templates, or using one of these third party packages. That's not always the case with every framework. I mean, I appreciate that Django provides that flexible ability, but I think it is a little bit. It's more a little more effort than some other web frameworks on this part.
Carlton Gibson 7:07
Yeah. And when I was first learning Django, I was like, Why? Why aren't there templates for this? That was
Will Vincent 7:13
exactly my thought and what
Carlton Gibson 7:14
exactly then but if you type, if you type Django registration templates into Google, it's amazing. You'll find very quickly that these, these do exist. But yeah, I
Will Vincent 7:24
mean, I mean, it's the tension between flexibility and ease of use. You know, Django is eminently customizable, but means a little bit more effort, which, you know, you appreciate, as you advance in your career, but getting started. It's like, wow, I'm gonna do it the way you know, rails does it or something.
Carlton Gibson 7:38
Yeah, I don't know. I mean, I still part of me. You know, if I start a new project, and I still come up against this problem, I'm like, oh, I've got to dig out these templates. Like, why doesn't this exist?
Will Vincent 7:50
If you want to save time on this, there are some Django starter projects out there. Django cookie cutter is the largest one. I have one as well Django apps. Which is a little bit simpler, which just gives you signup forms email option, because it's sort of the same, I do the same steps in every project, it does feel a little bit like doing the same thing over and over again. But people's use cases are different, and Django allows for that. So that's why these packages exist.
Carlton Gibson 8:16
But if you are just looking for sign up templates, there are as you say, these there are these examples which you can either just use as your starting point for your project, or if you've already started your project, you can just copy the templates across and there they make a great template, a great starting point, a great foundation you can
Will Vincent 8:33
do and customize. And the other part of this is you know, because an email will be sent you need to configure email in Django. So that's you can usually when you're getting testing it locally, you can have it output the emails to your your console, your command line, but then you need to plug in an email service and that's another hurdle for people learning how to do this that once you've done it, you realize oh, it's just a couple lines in your your settings.py file, but the first time it's confusing cover all this, like cover all this in my book Django for beginners, but I'm sure you
Carlton Gibson 9:06
But yeah, I mean that's another thing is like, Well how do I send an email? Well, I have to configure smtp. Well, can I just use Gmail? See? Well, yeah, we used to be able to what are they used to be able to? But what are the configuration data?
Will Vincent 9:16
Yeah, you can't do that anymore. No, they they used to be able to just use Gmail. I may be a year dated with this, but they changed it around. So you, you have to jump through all these hoops, and you basically can't do that anymore. You could 334 years ago. That's the way I did it. Okay, Google change something around that. So you, you really need to just use a service, you know, sendgrid mailgun. There's a whole host of them.
Carlton Gibson 9:39
Amazon's SEO Yes, simple email service. Very,
Will Vincent 9:42
doesn't really matter which one. I mean, I like that. Yeah, all
Carlton Gibson 9:45
of the bit. They all do the same. If you type in if you type in whichever backends you want to use Django sendgrid. Like they'll be a third party package which wraps it up in an email back end and you just put two lines in your settings file and configure this and it will do Work?
Will Vincent 10:00
Yeah, yeah, I mean email we get so done email, but it, it can get a little complicated. But with SMTP, you basically get an API key and you just a couple lines in your settings.py file. So you sign up for the account, you plug it into your settings.py file, you tell Django. Okay, output emails to SMTP, not the console. and away you go. Anyway, so Django gives you lots of flexibility here. But there are these hurdles, if you're learning it for the first time, but then later, you appreciate them. So let's talk about API's. So this is where it gets real. Because now you gotta you don't just you know, I didn't know about sessions and cookies in Django for I would say, at least a year into it, because I didn't need to. I just, you know, we're just was
Carlton Gibson 10:40
just worse, right? Yeah, it just works. So you don't need to think about and Django
Will Vincent 10:43
is my first web framework, so I didn't know anything about anything. So you know, that's why I upfront mentioned sessions cookies, and this matters with API's because it
Carlton Gibson 10:53
as well people think oh, you know, will, couldn't this be better. In my day you had to do all this by hand. You had to you know, send The setcookie header, the header, and it was you get this wrong every time. And this is where Django doing it for you and providing the auth framework and the sessions framework. And it matters so much because you won't make these mistakes. And you don't have to build that stuff.
Will Vincent 11:14
Right? So you really don't want to mess this up. You really don't want to mess up this party.
Carlton Gibson 11:18
You know, I mean, you know, and you'd let you get session leakage problems and I was just a nightmare and well, you know, dang that. That's, anyway, we've we've talked about this love two times, but that Django provides it for you is just such a resource. Such a, you know, blessing.
Will Vincent 11:33
Yeah, one of a better word. So Carlton, co maintainer of Django rest framework, why don't you explain why are there four built in methods? And not just one Not to mention all the third party methods? What, what's going on there?
Carlton Gibson 11:44
Well, authentication is complex, right? So back in the day, we used to use HTTP basic auth. With you, your browser still does it. And I still use it quite, you know, not all the time, but from time to time, I'll still be like, I just need some more HTTP basic. Because then you get that little browser delivered, pop down. And you can just type a password. It's great for bootstrapping something. But sometimes you want to send the password in the username with the request and have it authenticated. So that would be HTTP basic auth. Sometimes if you're in a browser, you can just use the same session or Django uses for a normal website. So for instance, if you're using an API to augment your website, so say, I don't know you've got a form, which you want to augment with Ajax, and you use an API endpoint to submit the data so that you don't avoid a full page refresh or whatever. Then you would just use sessions. And if you can use session of do because it's the existing cookie, the existing login, agreed, yeah. It's, it's fantastic. And then you want to go on to Well, what about multiple devices. And so from your mobile phone from a native app on a mobile phone, you have to use some kind of token, which is like a, like a key. So authentication is something you've got, it's like I've got a password or I've got a token With a with a with a long number which you ident uniquely identifies me, no one else has got this. So an app can authenticate with the API using the token of some kind, and Django rest framework ships with a very simple token authentication. implementation. It's not designed for building Twitter or building Facebook or building Instagram is designed for small sites who just need a very simple implementation, then there are more complicated ones. So something like JavaScript web tokens are very popular now. Right. Tell us about
Will Vincent 13:34
those. Well, they these are these are thanks for funding. Now. Let me too, you
Carlton Gibson 13:37
know, but Well, yeah, I know. I do things like refreshes, and they enable you to use multiple device but you talk because
Will Vincent 13:43
well, before we get to that wrote the book. Yeah. I wanted to ask you what's up with remote user auth? Because that's the fourth Tilton method. And I I have only an abstract understanding of this when I gave my my talk, a bunch of people ask me questions, and I found that people are using this in the real world but when I tried to just get configure it myself. Just,
Carlton Gibson 14:02
I couldn't do it. The times I've used this is in enterprise environment, and Django itself has remote Authentication Service rectangle rest framework. And the idea is that say you're, I don't know, a big company and you've got a single sign on server or, or something where people can authenticate. You can go and get an authentication from that third party authentication server. And then you can use that as the authenticate as the authentication source and say, yes, this is authenticated via that third party service. These things are very useful in those kind of environments where you've got an existing login. So maybe you've got a Django app already that has users in it and has people authenticated, and you want to create a separate Django app which uses the the user database from the other service, well, then that would be remote. That would be a use case for remote user authentication.
Will Vincent 14:53
Okay, you know, I remember there was people from University of Texas Austin, which has massive site and uses Django and they wanted
Carlton Gibson 15:01
to get really big in tech?
Will Vincent 15:02
Yeah. Okay. Okay, good. So for built in methods and just to reiterate so basic auth is the first one that's just email and password sent in clear text
Carlton Gibson 15:10
in will username and password. So
Will Vincent 15:12
sorry, username,
Carlton Gibson 15:14
but I write okay and that they are sending clear text. But this is why we're all using HTTP s.
Will Vincent 15:19
Right. But that's
Carlton Gibson 15:20
why it's because it puts in as part of the request. And so if it's not encrypted, they would be visible over the wire.
Will Vincent 15:27
Exactly. So basics fine for get up and going session with the next level. Use it if you can. So Django uses token auth. Again, so the what I don't know if you mentioned the issue with Why can't use sessions with multiple devices is because each session is unique. So that's why you have a token for you know, mobile setting, remote user authors, enterprise E, A, and then you get to JavaScript web tokens, which you'll see people saying, Oh, you have to use JavaScript web tokens. So this is a more complex token. Basically, there's long tutorials on it. basics before encoded, you can wrap up all sorts of information within it. The dominant third party tool for doing it with rest framework is Django rest framework simple JW T. And in my talk I, I talked through how to implement this. And in the there's a source code that goes along with it that has a working example. So yeah, the main reasons is the token auth, within Django framework is pretty basic. So you may not want, you may want your tokens to expire, or some period of time. In fact, you probably do, because otherwise, if it never expires, if someone got your token, they have full control. And JavaScript web tokens provide a lot of extra stuff, but I would say don't just jump into it unless you need it. Keep it as you both agree, keep it as simple as you can. You can change this as needed, but don't, don't just jump into some complex JW T. You know, there's all sorts of fun cool ways you can customize stuff. But if you don't do it unless you need to.
Carlton Gibson 16:58
Yeah, I mean, if you know If you're building a, if you're in a sort of team environment where you're building a public facing mobile, web and mobile application with multiple clients and multiple platforms, and you're in a team, and it's a proper business, and it's, you know, as I say, public facing, then JW T is probably something you want to be investing the time in and looking at. But if you're building a smaller app, which is kind of just you in your business team, it's only got, you know, a small number of users, then, you know, tokens are fine, like the token or that Django rest framework ships, it's fine for that. But you know, it depends on your use case, write it, yeah, don't step up to this full featured. We could build it anything system for the tiniest internal app, you know, if you're building a, an internal business tool application, you don't need a super high powered authentication system because you're not dealing with that with that kind of level of client.
Will Vincent 17:57
Agreed. So yeah, good default, use Use token auth. And if you need it JW T's are there for you. But there's also. And then there's this whole Oh, wasn't
Carlton Gibson 18:05
it. So OAuth is like where you've got a server which provides an identity, which then you go and authenticate with. And there's a behind the scenes handshake to make sure that you've built verification to make sure that you the the token that you got was correct. And then you get an access token, which enables the server behind the scenes to access your identity. And this is how social auth works. So if you log in with Twitter, or login with Facebook, or log in with Google, or log in with GitHub, you everyone's seen you know that, so and so application wants to access your username or your email address,
Will Vincent 18:39
without ever seeing your password. Yeah, that's where you'd use all and if and if you use Django, all auth, which we mentioned previously, it makes it very easy to implement social auth via OAuth for like 50 different platforms. So yeah, so
Carlton Gibson 18:56
for each provider for each platform, there's a provider and an order Provided which you just add as an extra install that. And then it's got the workflows in place for you to be able to authenticate with Twitter say,
Will Vincent 19:08
Yep, and I have, it's covered in the books. But I also have a I have a tutorial specifically on Django, all auth, which I think I've mentioned before. So we'll link to that people can take a look at how that's done. But then there's then there's another level which are these services. So this is like ortho or Okta, which you just completely kind of outsource the authentication piece. And to be honest, these are ones where I've read the tutorials will link to them. I've heard very prominent people advocate for these but I don't quite understand why you would other than smart people working on big projects are fairly strong advocates of these. I don't know, have you been in a case where you using one of these services is a better approach than using the built in tools?
Carlton Gibson 19:54
What's the use case the use case for me is if you want to avoid a certain amount of time building stuff around what's provided by Django itself. So if you, you don't need the login templates if you just use auto author, or zero, how do you say,
Will Vincent 20:10
Oh, yeah, it's probably zero. You're not sure. Bill
Carlton Gibson 20:12
zero, isn't it? Because it's zero effort. But that's the idea. But then you kind of lose as well, like, so it's the, in the end, you get JW t logins. And you can sort of from a front end app, it's very easy to communicate with that with the odd zero server and say, Yeah, they're locked in, you're logged in. But then you still need if you're going to do something in the Django world, you still need to create a user model in your Django database that's logged in via this third party service. And it's that bit that it's always broken down for me is that the promise of less work? Sort of faded away into the air is that hang on, this is more
Will Vincent 20:51
Yeah, well, that that was my experience as well as it was as much or more work and then a loss of control. But there's a reason why these services are popular and I think I just haven't had the use case. myself where it makes sense.
Carlton Gibson 21:02
It's again, are you bootstrapping something as a side project? Or is this your main business? If this is your main business, then you can't be outsourcing these fundamental parts of it. But if it's a side project that you're just trying to get knocked out on the weekend, then Sue because you get authentication sorted out,
Will Vincent 21:17
you know, I think we just lost them as potential sponsors, Carlton, but that's okay.
Carlton Gibson 21:20
Oh, yeah, maybe
Will Vincent 21:23
we'll get we'll get someone from there to come on and defend this point of view.
Carlton Gibson 21:27
Yeah, no,
Will Vincent 21:29
no, I think they use Yeah. It all the useful but it all depends. I mean, and that's what we're, you know, we try in this podcast to not make it a typical engineering, you know, it all depends we're trying to be to give you our opinions and argue for them and mention the other side. If somebody
Carlton Gibson 21:44
we use if someone who uses also wants to come and tell me why they use it, why it's great. I'm happy to listen, I'm Abdullah, but for me my experience of trying to implement with them and trying to work out how I could solve my own use case. It was just like, no, this is this. This isn't. This is taking my user database. And putting it on someone else's server.
Will Vincent 22:01
Well, in defense of them, I saw they just in the last couple weeks, have a very nice tutorial on building a Django project and using path zero, so we'll link to that.
Carlton Gibson 22:13
Yeah. And in fairness, my The last time I looked at it was two years ago. And you know, there was probably quite changed since then.
Will Vincent 22:20
Yeah. So what else anything else to say? I mean, I think authentication when I'm teaching beginners is one of the big parts of Django. Just because it doesn't just give it to you out of the box, you are required to configure your, your signup, registration forms. And then if you're building an API, you have to make a choice. You know, in practice, you use something like Django author Django registration on traditional Django. If you're doing an API, you use either token auth or JW T's if you need them. So you quickly become used to that, but it is a hurdle when you're learning Django.
Carlton Gibson 22:58
Yeah, and It's just part of the reality of building a web application that you need to handle authentication properly. So be grateful for what it does do for you be grateful that it doesn't put you in a position where you can blindly shoot yourself in the foot. You have to make certain choices, but allocate the time don't think, Oh, you know, I'll get authentication. All my authentication problems will be sorted out in 10 minutes. No, it's an ongoing thing that you need to constantly be looking at and working on. keep it as simple as you can. But when you need to step up a level, you have to allocate the time to step up a level because it's authentication. And you know, every week we see stories of sites being broken into and data, user data being stolen, because they're not secure. So you have to take
Will Vincent 23:45
take it serious, and it's me even, you know, Facebook, doing lots of things. But even Facebook, which has a very strong engineering team had millions and millions and millions of usernames and passwords being stored in clear text, which I don't even know how how could you even do that? I mean, clearly you can, but you know, Django sort of doesn't let you do that. When you date, it doesn't do database encryption by default,
Carlton Gibson 24:08
you have to opt into encrypted, encrypted at store. So well, you know, but passwords are stored encrypted. So they're, I mean, yeah, that's
Will Vincent 24:15
not saying like the passwords are not store, or even the password, or the passwords
Carlton Gibson 24:18
will include over Well,
Will Vincent 24:21
I don't know, I have seen that in many big companies. I thought that was the case with Facebook, but someone can correct me. But in any case, this stuff is tricky. And even the biggest companies get it wrong. And what was it, you know, and Docker Hub, just this week, you know, someone hacked in and so yeah, so if you implement these things properly, if you encrypt the passwords, encrypted database, then even if someone hacks in, they can't do as much damage and Django just gives you out of the box. The proper way to do it. Yeah,
Carlton Gibson 24:52
and Django does a very good job at password hashing and each major version was sort of bump up to the the algorithms and bump up the number of iterations of those algorithms with the password hashing. So that's kind of quite secure.
Will Vincent 25:07
One there. And then there's also you know, we were talking before we started recording, so the future of Django another the other add ons, you can do two factor authentication, which I think there's some efforts. So that's where you, you log in, then you have to confirm like through text message. There's third party packages that do this now with Django, but I think there's some work to potentially bring that into Django itself.
Carlton Gibson 25:26
Yeah, there's a lot of a lot of the core contributors are thinking in this area now. And so, you know, we don't have a timeline. But, you know, soon enough, Django will have, you know, either one time passwords or two factor authentication built into the core framework, as I say, there are third party apps that enable you to do this already. But it would be nice if that was part of core because as we get further on the username and password, login isn't enough. You know, most more and more services are requiring two factor, second factor auth
Will Vincent 25:58
Yeah, and as the web of it Django evolves with it. And I think actually at the sprints, I know some people were talking about working on just this very thing at some of the Django con sprints. So that's a, that's an example of, you know, a number of people talk online, they do their own things, and they come together at a conference and they can bang out, you know, some real progress. Yeah. Anyway,
Carlton Gibson 26:18
all right. What would I say? Some summary. I just say keep it, keep it simple. allocate the time, but keep it simple. Don't get it more complicated than you think. You know, don't build an over elaborate authentication system until you need it.
Will Vincent 26:29
Yeah. All right. As always, we are at Jango chat.com chango on Twitter. And if you have feedback or comments, suggestions for things we should cover, please let us know. We'll see you next time. Alright, see you next time. Bye. Bye.