Archive for February, 2014

An Approach to Token Based Key Distribution for Mobile Clients

Do not duplicate

Back during Rails Rumble 2013 the team I was on was building an application for use by peoples phones. We were deliberating on how we could easily get the application data from the server to the phone without having to resort to poor solutions like username/password combinations or some convoluted OAuth flow that requires embedding application secrets in the binary.

Token-based authentication is an approach I've heard of before and is used in popular applications such as Campfire. The one problem though is the key distribution isn't the nicest thing in the world. With Campfire the user is required to find their token, copy it then paste it in the correct location of their API consumer in order to interface with the product. While this might work alright for a desktop client, once you venture into mobile data entry can sometimes be a little tedious.

Our assumption for the application was that a user would be using the app from their desktop first. This would mean all their session data isn't available on their mobile device so in order to go somewhere to get the data they need would require logging in via their phones web browser and going through the same steps as described previously.

I wanted an easy way to get the information to our mobile clients that required very little in terms of technology. Our approach was to provide a link embedded in a QR Code that could be scanned by your phones barcode scanning application. Once you've scanned the code you now know where to go in order to grab the token that you need in order to get API access.

This Message will Self-Destruct in 5 Seconds

inspector gadget and stuff

There were a few things that needed to be taken care of when creating these URLs. Firstly, we couldn't lock the endpoints behind sessions since that would make it impossible to fetch the key. Secondly, it needed to be very hard for anyone to arbitrarily guess what the URL to get access to a token would be. Finally, we needed to be able to prevent "replay attacks" to the resource that contains the API token information.

In order to prevent people from guessing what the URL would be to get a token, we simply used UUIDs as the resource location. We had an object that held a reference to a token and would provide the token details when requested via JSON. This meant that whenever we needed to provide access to a token we could just create one off objects and link off to it's UUID identifier. Another added benefit is that if we wanted to we could regenerate another object that would reference the same token.

When it came to replay attacks, the main concern here was having someone watching traffic as it went by and clueing in that an endpoint is how keys were distributed. So what could possibly happen is I request my token, while this evil third party (let's call him Carçon) who is watching my requests also makes a request to get the same token. If we aren't careful we could accidentally give the API token to Carçon as well! The way we took care of this was by making it such that by looking at the token you destroy the external reference to it. In this case it would mean that when the attacker makes the request, instead of getting an API token they'd get a 404 instead since the object providing access was destroyed at the end of the initial request!

While I'm certain there are still some problems that might exist with this approach it felt like a novel way of solving the problem of key distribution. It also made much simpler for the developer writing our Android app since there they didn't need to store user credentials or do the OAuth dance.

Thoughts and Experiences from my first Global Game Jam


From January 24 – 26 was the Global Game Jam and I was determined to actually work on a game for once. After having missed my opportunity for Ludum Dare in December this had to happen. While there were a few last minute changes and I ended up working solo I was still going to build something. I decided to grab a few tools, some of which I already knew, others that I didn't, and roll with them. I had 48 hours to get something done and messing around with environments or learning something crazy new like Unity would've been a waste of time.

Knowing that I was by myself I made a few decisions about what I'd need to do. The big thing was I didn't have time for assets so I jumped onto Open Game Art and started looking for retro/8-bit style art that would match my roguelike dungeon crawler. This site ended up becoming the go-to for everything I needed.

There were a few issues with the assets though that needed some minor tweaking on my side. 8-bit and 16-bit style pixel art is somewhat popular, though one problem is often the images are extremely tiny. I fired up my image editor of choice and started making things a bit more realistic in size. There's various kinds of scaling algorithms but the one that works best for pixel style art is most definitely nearest neighbour. Other forms of scaling would leave the sprites looking alright but a tiny bit fuzzy which was definitely less than ideal.

Tiled Map Editor

With my re-sized sprite-sheet and sprites themselves I was ready to start building out my dungeons. This is where my game wasn't truly a roguelike since I wasn't procedurally creating rooms, but building them in this wonderful tool called Tiled. The purpose of a tool such as Tiled is to make it easier to build out maps that your games can use while also helping keep size down. Let's say you were to use a png to represent a very large level. There is a good chance the image would be very large and might even cause your performance to drop because of it. Tile maps on the other hand provide a bunch of meta-data about how your level looks and then you're able to only render what you need. Parts of this will include that sprite-sheet or map-sheet which your software will use in order to know what images to render on the screen. Another added benefit of at least Tiled is I was able to add objects which can be used for whatever. In my case I used them to represent the binding boxes of my rooms, where the player would start and where the exit of the dungeon was.

I'd experimented with Löve2D in the past and had learned enough Lua to at least be able to build something. I was still jumping into the Lua documentation to answer questions, but at least I was able to effectively put my ideas into code. Much of the game was built with a lot of write and run debugging, which worked for most things but started to get a little annoying. I'd run into the typical scripting language problems like "variable not defined" or "you used . instead of : on your function call" which was wearing me down a bit near the middle of day two. I normally build systems and pretty much always drive my design by unit tests. I was starting to work on my map bounds part and I knew that skimping out on testing because I'm making a game was going to cost more than finding a test framework, setting it up and using that. It didn't take too long before I found a tool that made the Rubyist in me pretty happy. There's a Löve2D testing framework called lovetest that gave me a really easy way to setup a test suite and run it. There was a simple naming convention to follow then everything else was like running Unit Tests in something like Ruby or Java. I was able to get immediate feedback and iterate on the errors much more quickly than I would've otherwise.

Another big tool I used during the jam was sleep. I knew going into it that I couldn't afford to run myself into the ground since I had a full time job to get back to on Monday. Getting sick because I pushed my body too far wasn't something I wanted, and besides I had a skiing trip the week after! While I didn't participate the full 48 or so hours, I think I ended up putting in about 27 or so. I noticed that there'd be a point during the day where things just weren't making sense anymore and I was making way too many mistakes. Sleep helped solve so many problems, it cleared my mind and kept me refreshed. I was also able to focus really well with very few distractions. I kinda feel that while I only spent about 26 hours or so building the game, they were all spent on building and not anything else like perusing Twitter or Reddit.

While my game worked I wouldn't say I finished it. Killing monsters doesn't quite work right, there's some collision detection issues, you can't die or beat a level. It does give me targets to keep working on and I was really in for building stuff and learning new things. For that I'd say it was a great success and I'm looking to participating in more to come!

SpellSword on Global Game Jam submissions site