Passing security token between back-end and front-end

While working on SlothCMS I encountered a problem, how to pass a security token between front-end and back-end. In this post I want to explore several possibilities.

Major assumption: HTTPS is standard.

Current situation

At the time of writing this post SlothCMS uses HTTP header item Authorization which follows the usual convention: Authorization: <type> <credentials> . As a type SlothCMS sends value Token  and as credentials hexadecimal string which is created from random 64 bytes in PHP on the back-end.

It’s probably not the standard solution and after giving it more thought it’s time to explore other solutions.

Alternatives

Cookie based

Most common implementation that I’ve seen so far is using cookies. It certainly has an advantage compared to keeping the data only while the session lasts, e.g. how it is currently implemented in SlothCMS.

Different Authorization header

JWT

JWT is an interesting variation of Authorization header which basically uses three strings encrypted by Base-64 algorithm. Those strings are:

  • header
  • payload
  • signature

First two are JSONs, hence the name JSON Web Token, and the third one is a string which confirms validity of those two JSONs.

At the moment this feels as an overkill for SlothCMS project but there will be time for more experimenting with this on SlothCMS project.

Query String

Query strings is something I was told not to do in the age of HTTP. The basic logic behind it is to put all credentials into URL after ?  which denotes start of the query string. An URL example would be: https://example.com?token=someToken&user=username.

There are several downsides for Query Strings:

  • browser history will retain access credentials
  • web server may store those credentials in logs
  • GET requests can be quite dangerous when it comes to sensitive data
  • devious bot can start generating random strings and can be lucky

Using body

The one way how to pass credentials between Front-end and Back-end which feels most icky is the last one. Basically it means mixing keeping credentials in the body. In case of JSON it would look like similar to this, depending on the actual implementation:

As you can see there’s a problem with having different types of information too close together.

If one were to use this type of credential passing, one would have to include at every end-point calls for authentication service.

Conclusion

My current implementation although custom doesn’t deviate from what is used in the wild, e.g. Amazon’s use of authorization headers, that much. In the future I plan to explore JWT a bit more.

Resources