For our REST API architecture, we are currently thinking over two options -

  1. Json Web Token - pros are that it is industry standard, we pass a key which adds a layer of access control and using which we can also add secondary authorisation restrictions at our backend, maintenance of session and related security features are provided by Django by default.

    Cons are that the params are open for anyone to see, it seems (and correct me if I'm mistaken) that it is possible that if someone gets access to our link, he could alter a param that is not linked with the core authentication process and thus compromise the data.

  2. An in house encryption process we developed that encrypts all the params. Pros are that we are fairly certain of it to have never been compromised, for even if the link would have gotten into the hands of someone they wouldn't have known how to decrypt it to look at the params.

    Cons are that we have to manage all the session data through our backend code in our tables, so we aren't able to utilize the Django features. Also, the idea that what we are doing isn't industry standard.

What is the right way to decide in this situation, and what are the factors that we should take into account?

  • Not knowing how to decrypt is only security by obscurity. Meaning, you are relaying on the fact that noone will ever find where the door knob is for the door, to get in. Eventually someone will find it and than what? – Raimonds Liepiņš Sep 11 '19 at 8:02

Don't roll your own crypto!

This is the golden rule of cryptography. If you do, your application will crash and burn, and all the hackers will laugh at you. It has been done time and time again, with companies boasting about how their "custom encryption algorithm" is perfectly safe, because it's closed source and no hacker could ever figure out how it works. Turns out that it had huge glaring issues and exploiting it was trivial, every single time.

Even expert cryptographers, who spent decades studying how to make good cryptographic algorithms, consider it extremely difficult to make an algorithm that is safe against all kinds of attacks.

But what should we do now?

That depends entirely on what your API actually does, and what you use these parameters for. What JSON Web Tokens do is "representing claims securely between two parties". If this is what your API needs, then you should absolutely go for JWT.

Basically, once the user has authenticated themselves to your API, the API can then generate a JWT and send it to the user, which they can use to authorize themselves on every subsequent claim.

But can't an attacker just copy my token and thus steal my authorization?

Yes, if you used plaintext communication. But you should not be using plaintext communication, you should be using HTTPS to secure everything.

So why would you actually use JWT then? Because it prevents the person you sent the token to from modifying the claim. If you sent

    "uid": 163495,
    "sub": "MechMK1",
    "role": "User"

to me, then I would not be able to modify the claim to set my role to "Admin", for instance, since then the signature would not be valid anymore.


If you are concerned about people being able to see the parameters of the JWT token, use JWE. Basically the encrypted version of JWT. Don't roll your own encryption.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.