Transcript: Authentication

I'm Carlton Gibson.

I'm here again with Will Vincent.

We're going to talk about authentication this week.

Well, Will, what's authentication?

I'm glad you asked.

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 we'll link to that.

And I'll try not to repeat all those points.

But uh a distinction is between Django and 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 is passed back and forth.

That's built into Django itself.

That's the predominant pattern with websites.

But as we'll get into with APIs, 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 service uses.

It works.

I don't think there's much to add on that.

Um now we've talked about this on another on one of the first episodes.

I use the bog standard model um because when I create a new project, I just want to get going.

My idea is my thought.

User profiles.

Oh, okay.

And then if I need to store additional fields on that, I'll create a w a profile model with a one-to-one field.

And Django does have this ability to create a um 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 conclusion, no, just use it and stick with it.

But that's my my take.

Yeah, yeah.

There's, as you mentioned, using the built-in user model and creating a profile um model for additional fields.

There is uh 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 a extend the built-in user model with abstract user, um, or you can abstract base user where you go a level deeper.

And so this is what you do if you want to, you know, so Django uses username, email, password, because that was the dominant pattern, whatever, 12, 12 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.

Um, but again, I think I I 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 I don't know, 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.

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, and you want to keep it nice and small with just a few fields.

And for me, another benefit of using Django Contrib.auth's user model is that it stops you doing that.

Is is it stops you falling into this trap where you added, you know, like this massive um life biography field to your your login model.

So do you do you do something to remove the username part of that, or do you just use

I'm I'm I think I'm old, you know, I'm like get off my lawn.

Um old cars.

Yeah, no, well, you know, I'm I'm I'm nearly in management age.

Um as my talk in Heilberg in Django Con Europe a couple of years ago was all about.

But um Yeah,

That's I first uh learned about you and reached out to you about that talk.

I sent you an email saying I really resonated with that talk about it.

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 um third-party packages around this.

And what that enables you to do very well is it sets up a custom authentication backend 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 um email logins, but on DjangoContrib.auth's user, um, 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 um machinery around that for the custom backend and when they 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 all auth for that, but I still like usernames because quite often you want a display name, you want you know a forum or a um you know a an ability to see what user is without using their their real name and without using their user ID, which is potentially sensitive.

And so I I still like usernames.

So normally you want uh a user signs up, you you have to you get an email and you have to click the link to verify you're real, right?

So Django registration gives you all of that and it's good.

It's by James Bennett, who's big can big longtime contributor to Django.

Yeah.

And member of the DSF board, actually.

So Django does not, which is uh partly why these things come about.

Django does give you the login and log out forms, but you have to do the sign-up page yourself.

So that involves views, URLs, templates, or using one of these third-party packages.

Uh that's not always the case with every framework.

I mean, I appreciate that Django provides that flexibility, but I think it is a little bit it's more a little more effort than um some other web frameworks on this part.

And but if you type if you type Django registration templates into Google, it's amazing.

You'll find very quickly that these all these do exist.

But yeah, I mean

Uh you know, Django is eminently customizable, but uh means a little bit more effort, which you know you appreciate as you advance in your career, but getting started, it's like, oh, why isn't it do it the way you know Rails does it or something?

I mean, I I still part of me th, you know, if I start a new project and I still I come up against this problem.

Oh, I'm like, oh, I've got to dig out these templates from uh why doesn't this exist?

Uh Django Cookie Cutter is the largest one.

Um I have one as well, Django X, which is a little bit simpler, which just gives you sign-up forms, email option, um, because uh it's sort of the same.

I do the same steps in every project, and 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.

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 um you can usually when you're getting it 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.

Um I cover all this, I cover all this in my book, Django for Beginners, but I'm sure you're not gonna be able to do it.

Yeah, there you are.

Uh but yeah, I mean that's another thing.

It's like, well, how do I send an email?

Well, I have to configure SMTP.

Well, can I just use Gmail say?

Well, yeah, you can see it.

Well, you but what are the things that you're

Yeah, you can't do that anymore, no?

I maybe a year uh 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 three, three, four years ago.

That's the way I did it.

Oh, okay, okay.

Google changed something around that.

So you you really need to just use a service, you know, Sengrid, Mailgun.

There's a whole butt whole host of them.

They all do the same thing.

If you type in, if you type in whichever backend you want to use, Django Sengrid, like there'll be a third-party package which wraps it up in an email backend, and you just put two lines in your settings file and configure this, and it will just work.

Yeah.

Yeah.

I mean, email we could we could do a whole episode on email, but it it it can get a little complicated.

But with SMTP, you basically get an API key and you just put a couple lines in your settings.py file.

So you sign up for the account, you plug it into your um settings.py file, you tell Django, okay, I'll put emails to SMTP, not the console, and away you go.

Anyways, 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 APIs.

So this is where it gets real.

Um, 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, it just works.

It just works, right?

So you don't need to think about sessions.

Um so you know, that's why I I up front mentioned sessions cookies.

Uh and this matters with APIs because

Uh in my day you had to do all this by hand.

You had to, you know, send the set cooker header, and it was you get this wrong every time.

And this is where Django doing it f 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.

And you really don't want to mess this up.

You really don't want to mess up this part of your screen.

I mean, you you know, and you'd look you'd get session leakage problems, and uh, it was just a nightmare.

And well, you know, Django that that's anyway, we've we've talked about this loads of times, but this that Django provides it for you is just such a resource, such a good you know, blessing.

Yeah, one of a better word.

What what's going on there?

So back back in the day, um we used to use HTTP basic auth, which you'd your browser still does this, and I still use it quite, you know, not all the time, but from time to time I'll still be like, ah, I just need some auth, http basic auth, because then you get that little browser delivered pop-down and you can just type a password, and it's great for bootstrapping something, but sometimes you you want to send the password and 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 auth that Django uses for a normal website.

So, for instance, if you're using an API to augment your website, so say um, I don't know, you've got uh a jet a form which you want to augment with Ajax and you 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 session authors.

And if you can use session auth, do because it's the existing cookie, the existing login.

Agreed, yeah.

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, um, which is like a it's 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 the with the with a long number which you identi uniquely identifies me.

No one else has got this.

So an app can authenticate with the API using a token of some kind.

And Django Rest framework ships with a very simple token authentication um implementation.

It's not designed for building Twitter or building Facebook or building Instagram, it's designed for um small sites who just need a very simple implementation.

Then there are more complicated ones.

So um something like uh JavaScript web tokens are very popular now, right?

Uh tell us about that as well.

Yeah, well, I wanted to ask you uh what's up with remote user auth?

Because that's the fourth built-in method.

And I I have only an abstract understanding of this.

When I gave my my talk, a bunch of people asked me questions and I found that people are using this in the real world, but when I tried to just configure it myself, I was just I couldn't do it.

And Django itself has remote um authentication, and so does Django Rest framework.

And the idea is that say you're, I don't know, um AM 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 authentic as the authentication source and say, yes, this is authenticated for via that that third-party service.

Um 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 um user authentication.

You know, I I remember there was people from um University of Texas Austin, which has massive site and uses Django, and they're one of the people folks who use it.

Okay.

Okay, good.

So four built-in methods, and just to reiterate, so basic auth is the first one.

That's just email and password sent in clear text.

Um in the case.

Well, username and password.

So it's just username credentials.

But that's why it's because

So basics fine for get up and going, session will be the next level, use it if you can.

So Django uses token auth again.

Uh so the well, I don't know if you mentioned the issue with why can't you use sessions with uh multiple devices is because each session is unique.

So that's why you you have a token for you know mobile setting, remote user auth is enterprise y AI.

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, it's base64 encoded.

You can wrap up all sorts of information within it.

Um the dominant third-party uh tool for doing it with REST Framework is uh Django REST Framework simple JWT.

And uh in my talk, I I talked through how to implement this and in the there's a source code um that goes along with it that has a a working example.

So yeah, the main reasons is the token auth within Django Rest Framework is pretty basic.

So you may not want you may want your tokens to expire over some period of time.

In fact, you probably do, because otherwise, if it never expires, if someone grabs 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 know, both of us agree, keep it as simple as you can.

You can change this as needed, but don't don't just jump into some complex JWT, you know.

There's all sorts of fun, cool ways you can uh customize stuff, um, but if you don't do it unless you need to.

But if you're building a um smaller app, which is kind of just you your it your business team, it's only got you know a small number of users, then you know, tokens are fine.

Like the the token author Django Rest framework ships is it is fine for that.

But you know, it depends on your use case, right?

It yeah, don't step up to the this full featured we could build it anything system for the tiniest internal app.

You know, if you're building a 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 clients.

So yeah, a good default use use token auth, and if you need it, JWTs are there for you.

But there's also

So OAuth is like where you've got a server which provides an identity, which then you go and um authenticate with, and there's a behind-the-scenes handshake to make sure that you've or verification to make sure that you the 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 log in with Facebook or log in with Google, um log in with GitHub, you everyone's seen.

You know, the so-and-so application wants to access your username or your um email address without ever seeing your password.

Yeah, that's where you'd use OAuth.

People can take a look at how that's done.

Um but then there's then there's another level, which are these services.

So this is like Autho or Okta, which um you just completely kind of outsource the authentication piece and to be honest these are ones where I've read the tutorials we'll we'll 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 um are fairly strong advocates of these.

I don't know if have you been in a case or where you you know using one of these services is a better approach than using the built-in tools?

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 you don't need the login templates if you just use author or zero how do you say it um

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 ah I it's that bit that it's always broken down for me is that the the promise of less work um sort of faded away into the air.

It was like hang on this is more work.

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 super because you get authentication sorted out you know

So what else?

Anything else to say?

You required to configure your your sign up 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 all auth or Django registration on traditional Django.

If you're doing an API you use either token auth or JWTs if you need them.

So you quickly become used to that but it is a a a hurdle when you're learning Django.

So be grateful for what it does do for you.

Be grateful that it 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 get authentication all my authentication problems will be sorted out in 10 minutes.

No it's 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 um broken into and data uh user data being stolen because they're not secure so you have to take take it seriously.

I mean clearly you can but you know Django sort of doesn't let you do that.

You have to opt into encrypted data encrypted at store so you know but passwords are stored encrypted.

So that I mean it's not a lot of

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 uh well was it uh you know in a Docker hub just this week you know did someone hacked in and so yeah so if you implement these things properly if you encrypt the passwords encrypt your 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.

So that's kind of quite secure.

-factor second factor rules.

Anyway all right what would I say the some summary I'd 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 until you need it.

Yeah.

We'll see you next time.