Year: 2017

Categories
Python

Django REST Framework: JSON Web Tokens (JWT)

(This post is a part of a tutorial series on Building REST APIs in Django)

Our last post was about Authentication and Permissions and we covered the available methods of authentication in Django REST Framework. In that post, we learned how to use the built in Token based authentication in DRF. In this post, we will learn more about JSON Web Tokens aka JWT and we will see if JWT can be a better authentication mechanism for securing our REST APIs.

Understanding JSON Web Tokens (JWTs)

We have actually written a detailed blog post about JSON Web Tokens earlier. In case you have missed it, you probably should read it first. We have also described how to use JWT with Flask – reading that one might also help better understand how things work. And of course, we will briefly cover the idea of JWT in this post as well.

If we want to put it simply – you take some data in JSON format, you hash it with a secret and you get a string that you use as a token. You (your web app actually) pass this token to the user when s/he logs in. The user takes the token and on subsequent requests, passes it back in the “Authorization” header. The web app now takes this token back, “decodes” it back to the original JSON payload. It can now read the stored data (identity of the user, token expiry and other data which was embedded in the JSON). While decoding, the same secret is used, so third party attackers can’t just forge a JWT. We would want our token to be small in size, so the JSON payload is usually intentionally kept small. And of course, it should not contain any sensitive information like user password.

JWT vs DRF’s Token Based Authentication

So in our last blog post, we saw Django REST Framework includes a token based authentication system which can generate a token for the user. That works fine, right? Why would we want to switch to JSON Web Tokens instead of that?

Let’s first see how DRF generates the tokens:

It’s just random. The token generated can not be anyway related to the user that it belongs to. So how does it associate a token with an user? It stores the token and a reference to the user in a table in database. Here comes the first point – while using DRF’s token based auth, we need to query database on every request (unless of course we have cached that token which). But what if we have multiple application servers? Now we need all our application servers to connect to the same database or same cache server. How will that scale when the project gets really really big? What if we want to provide single sign on across multiple services? We will need to maintain a central auth service where other services request to verify a token. Can JWT simplify these for us?

JWT is just an encoded (read – hashed / signed) JSON data. As long as any webservice has access to the secret used in signing the data, it can also decode and read the embedded data. It doesn’t need any database calls. You can generate the token from one service and other services can read and verify it just fine. It’s more efficient and simply scales better.

JWT in Django REST Framework

DRF does not directly support JWTs out of the box. But there’s an excellent package that adds support for it. Let’s see how easily we can integrate JWT in our REST APIs.

Install and Configure

Let’s first install the package using pip –

That should install the package. Now we need to add rest_framework_jwt.authentication.JSONWebTokenAuthentication to the default authentication classes in REST Framework settings.

We added it to the top of the list. Next, we just have to add it’s built in view to our urlpatterns.

Obtain a Token

The obtain_jwt_token view will check the user credentials and provide a JWT if everything goes alright. Let’s try it.

Awesome, everything worked just fine. We have got our token too. What do we do next? We use this token to access a secured resource.

Using the obtained JWT

We need to pass the token in the form of JWT <token> as the value of the Authorization header. Here’s a sample curl request:

So our token worked fine! Cool!

Where to go next?

Now that you have seen how simple and easy it is to add JSON Web Token based authentication to Django REST Framework, you probably should dive deeper into the package documentation. Specially these topics might be interesting –

  • Refresh Tokens: If you enable JWT token refreshing, you can exchange your current token with a new, fresh one before the existing one expires. The new token will of course have a renewed expiry time set.
  • Verify Token: If you just share the secret, all services can verify the user on their own. However, in modern micro service based architecture, you may want to provide an API end point that other services can use to verify a JWT they received from the user. This can be useful for those scenarios.
  • And of course look at the settings options available and see how you can customize the token generation process.

In the future, we shall try to cover more about Django, Django REST Framework and Python in general. If you liked the content, please subscribe to the mailing list so we can notify you when we post new contents.

Categories
Kotlin

Kotlin: An Introduction

In Google I/O 2017, Kotlin was announced as an officially supported language for android development. The news created a massive buzz among the developers community. Google is a big name and so is Android. So that level of attention was only natural. But many of those who have followed the language since it’s inception, didn’t need to wait this long to fall in love with the language. Kotlin is a brilliant language. It’s statically typed yet quite productive. The syntax does not feel rigid or restrictive, rather it feels rather expressive and enjoyable. Writing code in Kotlin is really fun. You don’t have to trust my word for that, just give it a try.

History of Kotlin

In case you didn’t know, Kotlin is named after the Kotlin Island near Saint Petersburg, Russia. You can read more about the Island in Wikipedia. So another programming language named after an Island, but why? Well, Kotlin is developed by those awesome guys at Jetbrains  who build our favorite IDEs. Apparently Kotlin was developed in their Saint Petersburg office and the developers named it after the Island.

Jetbrains was using Java to build their IDEs but why did they decide to create a language of their own? The answer is probably obvious to you by now. Every new language is created out of frustration from the existing ones. We already saw a similar story in our post about Golang. The same thing happened here too. Jetbrains lead Dmitry Jemerov mentioned they were looking for features not offered by Java or most other languages. They liked Scala but the compile time was a bugger. So they came up with Kotlin and thanks to them that they did!

Work on Kotlin started in 2010 and Jetbrains announced the language publicly in July 2011. They made the project open source under the Apache 2 License in 2012. They continued developing the language by accepting and reviewing user’s feedback. After a lot of improvements and iteration, the language reached version 1.0 in February 2016, the first officially stable release with commitment towards backward compatibility. That was just a year go. Kotlin became quickly popular and developers seemed to love it. Many large companies started adopting it even before it became officially supported on Android. But the official support didn’t take long either, in Google I/O 2017, first class support came for Kotlin on Android.

Write once, Run Everywhere

Do you recognize the words – “Write once, run anywhere / everywhere”? If you’re a Java developer, you might recognize them. Kotlin takes things a little bit further than that. Kotlin started off as a language based on the JVM. You could run Kotlin anywhere you could run Java. But that’s not all, Kotlin code now can be transpiled into Javascript too! You already know it works on Android. The guys are also working on a native version based on LLVM. Once that happens, you can truly write code once and run them anywhere and everywhere. Of course you can’t fully port all codes from one platform to another, for example if you’re using JavaFX on the JVM, those will not work on the browser. But the common business logic can be ported without much efforts in most cases.

Kotlin is fully interoperable with Java and can take advantage of the JVM. So the plethora of existing Java libraries and packages are at your disposal. This opens up enormous possibilities and a large eco system to the enterprising Kotlin developer.

Most Loved Kotlin Features

So what makes Kotlin great? Why do people love it? Here are some of the features people love in the language:

  • Full interoperability with Java (and the JVM)
  • Multi platform – JVM, Android, Browser and Native (coming soon)
  • The syntax is quite similar to other popular programming languages. Expressive and productive.
  • Type inference is another cool feature. You can just write val number = 23 and it an identify that it’s an Int. You can of course declare the type if you wish 🙂
  • The when block can cut the need of complex if/else block or switch statements and makes things simpler.
  • Libraries like Anko not only makes android development faster, it also makes if more enjoyable. Also the android extensions for Kotlin makes many pain points easier to handle.
  • Functions are fun, literally 😉 fun meaningOfLife() = 42 – see? fun – it is! 😀
  • Simple one line functions paired with string interpolation is pretty useful – fun fullName() = "${first} ${last}"
  • The idea of data class is to provide easy POJOs in a very short, concise manner.
  • Operator overloading is quite simple.
  • You can add extension functions to classes, even built in ones, easily extending their functionality.
  • Kotlin provides null safety by forcing you to check nullable types for null first. No more NullPointerException for you! 😉
  • Lambdas are super fun. Expressive, powerful and of course productive.
  • Easy to use and useful ranges.
  • Easy to add custom get and set methods to public fields. Pair that with simple functions. You have got properties without much boilerplate code.
  • The default arguments and named arguments are pretty cool
  • You can use == for checking equality, no need for equals calls.
  • The is operator provides automatic smart casts. When you write if (param is String) { // code }, the param is cast into a string for you in the block. So no more instance checks.
  • Super expressive maps, filters with lambdas
  • Ability to create custom DSLs
  • Coroutines
  • Awesome tooling support. IntelliJ Idea lets you convert Java code to Kotlin in just a click. You know their IDE is the best, right? But there’s also support for other popular IDEs like Eclipse.

Learning Kotlin

You can also visit us on the Facebook, we have a group named – Kotlin Ninja where some Kotlin enthusiasts learn and share together 🙂

Categories
Python

Django REST Framework: Authentication and Permissions

(This post is a part of a tutorial series on Building REST APIs in Django)

In our last post about ViewSet, ModelViewSet and Router, we saw how easily we can create REST APIs with the awesome Django REST Framework. In this blog post, we would see how we can secure our endpoints with user authentication and permissions. Authentication will help us identify which user is currently logged in and permissions will decide which user(s) can access which resources.

Authentication

The idea of authentication is pretty simple. When a new incoming request comes, we have to check the request and see if we can identify any user credentials along with it. If you have read the Flask HTTP Auth tutorial or the one about JWT, you might remember how we were checking the authorization header to authenticate our users. We might also receive the user login data via a POST request (form submission) or the user may already be logged in and we can identify using the session data.

We can see that the authentication mechanism can largely vary. Django REST Framework is very flexible in accommodating them. We can give DRF a list of classes, DRF will run the authenticate method on those classes. As soon as a class successfully authenticates the user, the return values from the call is set to request.user and request.auth. If none of the classes manage to authenticate the user, then the user is set to django.contrib.auth.models.AnonymousUser .

We can set these classes using the DEFAULT_AUTHENTICATION_CLASSES settings under the DRF settings. Here’s an example:

In the example above we used BasicAuthentication and SessionAuthentication – two of the built in classes from Django REST Framework. We will look at how they work and we will also check how we can write our own class for our custom authentication.

(PS: Here we set the authentication policy globally, for all views / paths / resources – if we want, we can also use different authentication mechanism for each one, individually but that is usually not done in most cases).

Basic Authentication

In our example before, we mentioned the BasicAuthentication class. This class first checks the http authorization header (HTTP_AUTHORIZATION in request.META ). If the header contains appropriate string (something like Basic <Base64 Encoded Login>), it will decode the string, split the username, password and try to authenticate the user.

Basic Authentication is very simple, easy to setup and might be quite convenient for testing / debugging but I would highly discourage using this method on production.

Session Authentication

If you have used Django, you already know about session based authentication. In fact, Django itself handles the session based auth and sets the user as part of the request object (an instance of HttpRequest object. DRF just reads the user data from the request and checks for CSRF. That’s it.

Session Authentication works very well if your users are interacting with your API on the web, perhaps using ajax calls? In such cases, if the user is once logged in, his/her auth is stored in the session and we can depend on those data while making requests from our web app. However, this will not work well if the client doesn’t or can not accept cookies (apps on different domains, mobile or desktop apps, other micro services etc).

Token Authentication

If you understand JWT, this one will feel similar, except in this case, the token will be just a “token”, no JSON or no signing. The user logs in and gets a token. On subsequent requests, this token must be passed as part of the authorization header.

To use token based auth, we first need to add the rest_framework.authtoken app to the INSTALLED_APPS list in your settings.py file. And then run the migration to create the related tables.

We also need to add the TokenAuthentication class to our DRF auth class list:

Now let’s create a view to issue tokens to user.

The code here should be self explanatory. We take username and password. We then try to authenticate the user using Django’s default authentication (checking username and password against what’s stored in the database). If the authentication fails, we return error message along with http status code 401. If the authentication succeeds, we issue a token for the user and pass it in the response.

We need to add this view to our urlpatterns next:

Now let’s try it out:

So we’re getting the tokens successfully. Now to access a secured resource, we need to pass it as part of the authorization header. But how do we make a resource available only to a logged in user? Well, permissions come into play here.

Permissions

While authentication tells us which user is logged in (or not), it’s our responsibility to check if the current user (a valid logged in user or a guest, not logged in visitor) has access to the resource. Permissions can help us deal with that. Just like authentication, we can also set a class of permissions globally or on each resource individually. Let’s start with the IsAuthenticated permission first. Let’s add this to our SubscriberViewSet.

If we try to access subscribers without any authentication, we will get an error message now:

So let’s provide authentication using the token we got.

Now it works fine! There are many useful, already provided permission classes with Django REST Framework. You can find a list of them here http://www.django-rest-framework.org/api-guide/permissions/#api-reference.

Custom Authentication and Permissions

The authentication and permission classes which come with DRF are quite enough for many cases. But what if we needed to create our own? Let’s see how we can do that.

Writing a custom authentication class is very simple. You define your custom authenticate method which would receive the request object. You will have to return an instance of the default User model if authentication succeeds, otherwise raise an exception. You can also return an optional value for the auth object to be set on request. If our authentication method can not be used for this request, we should return None so other classes are tried.

Here’s an example from DRF docs:

In this example, the username is being retrieved from a custom header (X_USERNAME) and the rest is quite easy to understand.

Next, let’s see how we can create our custom permission class. For permissions, we can have two types of permissions – global permission or per object permission. Here’s an example of global permission from DRF docs:

If the has_permission method returns True then the user has permission, otherwise not. Let’s see the example for per object permission:

For dealing with per object permission, we can override the has_object_permission method. It can take the request, the view and the obj. We have to check if the current user can access the obj in question. Just like before, we need to return True or False to allow or deny the request.

In this blog post, we learned the basics of authentication and permissions. We now know how we can secure our API endpoints with DRF. While the token based authentication was very useful, we kind of like JWT. So in our next post, we will be using a third party package to implement JWT for Django REST Framework.