TL;DR: In this article we will cover building your first web application in Crystal. The application will utilise JSON Web Tokens (JWTs) to authenticate our users around the restricted resources of our app. The completed sample application can be found in this GitHub repo. I'd encourage you to check out the repo to follow, aside this tutorial.
Building your first Crystal Web App & Authenticating with JWTs
I wrote a technical article back in June titled "The Highs & Lows of Crystal". It was an introduction to the Crystal Language and an overview of my perspective on it, trying it out for the first time. I enjoyed trying out Crystal very much and the good news is that Crystal is still on the up, and more than ever people are trying it out, and finding that they really rather like it (just as I do!)
Today I'd like to share a guide on building your first Web App with Crystal, and using JSON Web Tokens (JWTs) to authenticate users in said application. Before we dive into the technical tutorial, for those who haven't read the previous article, and perhaps don't know about Crystal Language at all, I'd like to quickly introduce it.
"Crystal is a statically-typed, garbage collected language, boasting the speed, efficiency and type safety of a compiled language."
Tweet This
Crystal was introduced by its creator, Ary Borenszweig, back in mid-2014 as a general purpose, object-oriented language with the aim of giving speeds close to C/C++ and being heavily syntactically influenced by Ruby. Crystal is a statically-typed, garbage collected language, boasting the speed, efficiency and type safety of a compiled language.
Crystal runs on the LLVM, and although the feel of the language is rather similar to Ruby, Crystal compiles down to much more efficient code, with much greater processing speeds. It is also self-hosted with the Crystal compiler actually being written in Crystal itself. As I mentioned in my previous Crystal introduction, the language is built to support concurrency primitives right out of the box, and uses similar concurrency concepts (including lightweight threading) to languages like Golang and Elixir.
"Two of the things I like most about Crystal are the excellent built-in tooling available, and the ease with which you can bind C libraries."
Tweet This
Two of the things I like most about Crystal are the excellent built-in tooling available, and the ease with which you can bind C libraries. When I look at new languages, especially relatively immature languages, it's always very reassuring when the language has extensive built-in tooling available to help developers stay productive and happy! In Crystal, there are a bunch of tools that make hacking around in the language super fun, but also help us to stay on the right track with semantics and more. I touched on those topics in a bit more detail in my previous article.
So that's Crystal in a nutshell! And now we have that covered, we can get on with building our first Crystal web application, and authenticating our app users with JWTs. If you would like to see the completed sample application to follow along with this article, it can be found in this GitHub repo.
Web App concept TL;DR
The idea behind the web app that we're going to build is a community driven Coding Challenge app in which members of the Open Source community can set coding challenges, and other members of the community can take the challenge and provide the solution. The joy of this app would be that coding challenges would have a whole array of solutions, in many different languages. They could act as great learning resources to others in the developer community, alongside being a fantastic learning experience in solving the challenge itself. (An idea I'd love if someone were to build and launch in the real world!)
In our app members of the community will have to be authorised to post and access the coding challenges, and therefore we're going to need a means of authentication. For that, we're going to use JSON Web Tokens. We also need to store the challenges posted, for that we'll use standard MySQL as our database.
Installing Crystal Lang
If you run on a Mac, you can install Crystal through Homebrew. Simply run:
brew update
brew install crystal-lang
If you run on Debian or Ubuntu, you can install through apt-get:
sudo apt-get install crystal
One thing worth noting is that if you are going to install onto Ubuntu or Debian, you must first add the repository and signing key to your APT configuration. It's super simple to do, and instructions can be found here.
Alternatively, you can build from source with a tar.gz file. The latest files can be found on the releases page on GitHub: https://github.com/crystal-lang/crystal/releases.
Crystal does not yet have a direct Windows port but that being said, if you have Windows 10 onward you can install and run Crystal as normal through the Bash / Ubuntu for Windows Subsystem. Details for that can be found here.
To test your installation has worked successfully, simply type crystal
into your terminal, and you will have returned the Crystal CLI default menu. Now we have Crystal installed and working on our machines, we can get on with the fun part—building our app!
Creating our Project
For building our web app, we shall use the popular Crystal web micro-framework Kemal. Kemal is heavily influenced by Sinatra for Rubyists, and works in a very similar way. I can confirm it is a joy to use—being both simple and functional. Handily, we can scaffold our new project using Crystal's built-in project tooling. Switch into your development working directory, and run the command:
crystal init app challenger
With challenger
being the name I gave my application. Feel free to name your project whatever you wish! Open up the project in your chosen editor, and head over to the file shard.yml
in the project root. Much like having a Ruby Gems file, this YML file contains all of the dependencies for our project. Open up shard.yml
and add the following:
dependencies:
kemal:
github: kemalcr/kemal
branch: master
Once that's in, head back into your terminal and run shards install
. Doing this will pull down Kemal and its dependencies for us to utilise.
The main file in your project is located in the /src
directory and will be named with whatever you called your project, so for me it's: /src/challenger.cr
. This file will contain the routes for our Kemal app alongside the controller logic, some config for our Kemal app, and not much else. To get our app up and running immediately, open up that file and add in the following:
require "./challenge/*"
require "kemal"
module Challenger
get "/" do
render "src/challenge/views/home.ecr", "src/challenge/views/layouts/main.ecr"
end
Kemal.config.port = 6969
Kemal.run
end
The require statements at the beginning of the file are telling our app to include Kemal to serve pages, and to include the src/challenge
folder, which will contain files and folders necessary to our project such as Config, Models, Views, etc. Next, we have defined a route and instructed it to render two ECR files. This is because Kemal allows us to create layout templates, alongside file-specific views.
To enforce those views, create the layout file src/challenge/views/layouts/main.ecr
:
<html>
<head>
<title>Challenger // Coding Challenges</title>
<link rel="stylesheet" href="/css/main.css"/>
</head>
<body>
<section id="main">
<div class="container">
<%= content %>
</div>
</section>
<script src="/js/main.js"></script>
</body>
</html>
Now create the home view file src/challenge/views/home.ecr
, and enter in whatever you like. I simply included an <h1> tag
saying hello.
You can now test your application by running crystal run src/challenger.cr
from your terminal. Your app should now be running on whichever port you specified—in this case ":6969".
Setting up User Login with Auth0 Hosted Pages
Now that we've got the base of our app setup, we can move straight onto the good stuff, and the main reason we're all here—authenticating our users with JWTs. With Crystal being a young and relatively immature language, it's no huge surprise that there aren't really any existing user authentication frameworks that we could simply drop into our project, much like we would with Devise or Omniauth for Ruby / Rails. Happily however, we don't need one.
We're going to store our users with Auth0 meaning we don't even need a Users
table in our database. Auth0 has quickstart guides to pretty much all major languages, but again with Crystal being a fairly new language, it's up to us to build from scratch. However, Auth0 make this easy for us with good technology, and Crystal makes it a genuine pleasure to write.
The first thing to do is open up your Auth0 Dashboard and click on the Create Client button. For this app, we can create a Regular Web Application client, and name it Challenge or whatever you have titled your application.
Then, back in your chosen editor, we need to create some routes for our app. Open up /src/challenger.cr
and add the following routes:
get "/auth/login" do |env|
env.redirect "https://[YOUR_URL].auth0.com/authorize?client=[CLIENT_ID]"
end
get "/auth/callback" do |env|
# callback logic
end
get "/success" do |env|
# for forwarding people to
end
get "/auth/logout" do |env|
# log people out
end
These four routes are the basis for our authentication flow with Auth0. Since there are, as I stated earlier, no available authentication libraries for our users to log in—we will use Auth0's hosted pages. Note in the /auth/login
route, we have created a redirect. This redirect will send users straight to our Auth0 hosted login page whenever they access the /auth/login route.
Once you've added these routes, open up your Auth0 app settings again, scroll down on the settings tab for your app and add into the Allowed Callback URL
section:
http://localhost:6969/auth/callback
We haven't created the callback logic in our app just yet, but this is the route we will assign to it, so we can fill that in already.
Create Login Callback & Get JWT
If you were to boot your application and run through the login process now, you would see that once successfully logged in, you would simply be presented with the /auth/callback
page—entirely blank, but with a URL param titled ?code=
. The way in which the process works can be found in the Access Token Documentation, that code actually being our Auth0 Access Token. To turn this Access Code into a usable JWT that we can pass around our application to authorise our user, we need to silently POST that code, alongside our App ID and Secret back to Auth0 to verify and exchange for a JWT. To do this, we shall create a module named Auth that will handle this in the background, on our /auth/callback
.
Create a file in the /src
directory of your application named auth.cr
, and add in the following:
require "http/client"
require "json"
module Auth
extend self
def get_auth_token(id_code)
id = id_code
uri = URI.parse("https://[YOUR_DOMAIN].auth0.com/oauth/token")
request = HTTP::Client.post(uri,
headers: HTTP::Headers{"content-type" => "application/json"},
body: "{\"grant_type\":\"authorization_code\",\"client_id\": \"[CLIENT_ID]\",\"client_secret\": \"[CLIENT_SECRET]\",\"code\": \"#{id}\",\"redirect_uri\": \"http://localhost:6969/auth/callback\"}")
response = request.body
res = get_jwt(response)
return res
end
end
In the above code, we are creating a module titled Auth that we can call in the background from our application. We have defined a method called get_auth_token
which takes the argument of id_code
sent from the successful login of our hosted login. We then need to send a request to [YOUR_domain].auth0.com/oauth/token
to exhange this for a usable JWT.
Using the http/client
library, we can construct a request that sends a JSON blob containing our client_id
, client_secret
, code
, and redirect_uri
to Auth0 for verification. Note that the code
value here is a string-interpolation of the Access Code
we received back as a URL param from the Auth0 login.
Also at the end of this method, we are calling another method titled get_jwt()
that takes the returned JSON blob as its argument. Let's create that method now, in the same Auth module:
class Token
JSON.mapping(
access_token: String,
id_token: String,
expires_in: Int32,
token_type: String,
)
end
def get_jwt(auth_code)
auth = auth_code
value = Token.from_json(%(#{auth}))
jwt = value.id_token
return jwt
end
To extract the usable JWT from the JSON blob that was returned in the last method call, we can use Crystal's super-handy JSON.mapping
functionality. We have defined a class titled Token
that we can push the JSON blob into, to create usable values. In defining the get_jwt()
method, we are doing that value push into the Token
object, and returning just the id_token
value. This id_token
is our actual, usable JWT containing our encoded user's details that we will use to authorise them around our application.
Now that we have our Auth module created, we can head back to our main src/challenger.cr
file, require the module, and call it from our /auth/callback route:
require "./auth"
get "/auth/callback" do |env|
code = env.params.query["code"]
jwt = Auth.get_auth_token(code)
env.response.headers["Authorization"] = "Bearer #{jwt}"
end
So when a user successfully logs in, their Access Token will be sent to our /auth/callback
route, extracted from the URL params and used to call our Auth module which will return the usable JWT. We can then set this JWT in our HTTP Authorization Header and we're done... Or are we?
If you run your application now, you will realise that after successful login and setting of the JWT in the Authorization header, if you navigate to another page the header disappears entirely. This is because we need to actually store this JWT in LocalStorage either in a session or in a cookie. In this case, we are going to use a session, and happily there is a library built for Kemal to handle the creation of sessions.
Add the following into your shard.yml
file, and run shards install
:
kemal-session:
github: kemalcr/kemal-session
Setting the JWT in a User Session
We now need to set up kemal-session
to carry our JWT Authorization header. In your main src/challenger.cr
file, remember to require kemal-session, and add in the following before your route definitions:
Kemal::Session.config do |config|
config.cookie_name = "sess_id"
config.secret = "[SOME_SECRET]"
config.gc_interval = 1.minutes
end
class UserStorableObject
JSON.mapping({
id_token: String
})
include Kemal::Session::StorableObject
def initialize(@id_token : String); end
end
To generate a strong config.secret
, you can run the following and copy / paste the result:
crystal eval 'require "secure_random"; puts SecureRandom.hex(64)'
Once again here, we are going to create a class to which we can JSON_map
values. The only value we need is the id_token
here, as this will be our encoded JWT value. Back to our auth/callback
route, we can update it to the following:
get "/auth/callback" do |env|
code = env.params.query["code"]
jwt = Auth.get_auth_token(code)
env.response.headers["Authorization"] = "Bearer #{jwt}" # Set the Auth header with JWT.
user = UserStorableObject.new(jwt)
env.session.object("user", user)
env.redirect "/success"
end
Note that we are creating a user
object from the jwt
value returned from our Auth module. We are then using that user
object to set as a session
, storing the encoded JWT which will now remain when the visitor navigates to another page. It's now worth updating our /auth/success
and /auth/logout
routes too:
get "/success" do |env|
user = env.session.object("user").as(UserStorableObject)
env.response.headers["Authorization"] = "Bearer #{user.id_token}"
render "src/challenge/views/success.ecr", "src/challenge/views/layouts/main.ecr"
end
get "/auth/logout" do |env|
env.session.destroy
render "src/challenge/views/logout.ecr", "src/challenge/views/layouts/main.ecr"
end
Great! We've got our encoded JWT being passed round in our Authorization HTTP Header, we have a successful login redirect, and even a way for the user to log out. We're not quite finished yet, though.
Decoding the JWT and Verifying Access
The whole reason we want to pass around a JWT in our HTTP Authorization header is to be able to decode and verify this token to check whether our users have access to restricted parts of our application. So what we need to do now is create another module that will decode our JWT, verify it and check that it contains an arbitrary attribute stating access levels for our application.
Before we build this module, head over to your Application Settings in the Auth0 Dashboard and change a couple of settings. Firstly, scroll down to the Advanced Settings of your application and click on the OAuth tab. The first setting we need to change here is the JsonWebToken Signature Algorithm
setting. Ensure that this is set to HS256 and not RS256.
The next setting is OIDC Conformant
. For now, just turn this off as it's not something we need to worry about, and may stop us from allowing login with username/password when using the hosted login. More information on that can be found in the OIDC Documentation—but for now, don't worry too much about it, just switch it off. Ensure you save these settings before moving on.
In this sample application we are not including an app-specific way for users to register, they can only do so through the hosted login. In doing so, we are not sending any custom attributes for the user, that they will need to be authorised in our app. Happily, Auth0 makes it very simple to do this, by applying a rule. Head into the Rules section directly below the Users section in the navigation. Click on the Create Rule button and select a blank rule. Name it add-member-meta
and have it reflect the following:
function(user, context, callback){
user.app_metadata = user.app_metadata || {};
// update the app_metadata that will be part of the response
user.app_metadata.roles = user.app_metadata.roles || [];
user.app_metadata.roles.push('member');
// persist the app_metadata update
auth0.users.updateAppMetadata(user.user_id, user.app_metadata)
.then(function(){
callback(null, user, context);
})
.catch(function(err){
callback(err);
});
}
Once we've done this, we need to tell Auth0 to return this value in the JWT. Create another rule, name it include-meta
and add the following:
function (user, context, callback) {
if (context.idToken && user.user_metadata) {
context.idToken.user_metadata = user.user_metadata;
}
if (context.idToken && user.app_metadata) {
context.idToken.app_metadata = user.app_metadata;
}
callback(null, user, context);
}
By setting this rule, Auth0 will now return the user_metadata
field in our JWT. This field contains our user's access level that we can verify before allowing them access to resources.
Moving on, head back into your project, add the Crystal jwt module to your shards.yml
file and run shards install
:
jwt:
github: crystal-community/jwt
Now, create a file named user.cr
in the base /src directory where we created the Auth module earlier. Have it reflect the following:
require "jwt"
require "json"
module User
extend self
@@verify_key = "[CLIENT_SECRET]"
def authorised?(user)
token = user
payload, header = JWT.decode(token, @@verify_key, "HS256")
roles = payload["app_metadata"].to_s
rs = roles.includes?("member")
puts rs
return
end
end
The first thing to note here is the @@verify_key
class variable. To decode our JWT, it needs a secret key. This secret key is actually the Client_Secret
defined in our Auth0 app management console. (The same one we used earlier when calling for our Auth Token).
Next, we have defined a method called authorised?()
that will take in the encoded JWT of our User as an argument. Then, we use the Crystal JWT library to decode the JWT using our Client Secret
as the secret key, and denoting the hashing algorithm to use as HS256
as we defined earlier in our application Advanced Settings / Oauth. Once decoded, we can check to confirm that the payload of the JWT contains our app_metadata
attribute of roles, and that it does reflect the user being a member
. We can then return the True / False value.
We know that the only parts of our application we want our users to be authorised to view are the coding challenges. Open up your main src/challenger.cr
file and add the following route definition, ensuring you include require "./user"
:
before_get "/challenges" do |env|
user = env.session.object("user").as(UserStorableObject)
auth = User.authorised?(user.id_token)
raise "Unauthorized" unless auth = true
end
Here we are using Kemal's before_get
directive to ensure this method is called before a user can call a resource. We are setting a user
object from the stored user JWT in the session, and calling our User.authorised?()
method on that user / JWT. Depending on the returned boolean, we are either raising a 401 Unauthorized, or allowing access.
Realistically, this is the crucial part of our application as it is the logic defining resource access from our user's JWT.
Extra: Adding the Coding Challenges
As this article is focusing on the use of JWTs for authorisation, I won't go into too much detail on the actual coding challenge objects themselves. For these coding challenges, and to make a slightly more complete app, I added in a SQL database and used the Granite-ORM
library to map the database data to objects. I created a model titled src/models/challenge.cr
which contained the following:
require "granite_orm/adapter/mysql"
class Challenge < Granite::ORM::Base
adapter mysql
field title : String
field details : String
field posted_by : String
timestamps
end
I then added some samples to the database, and set up the following routes:
get "/challenges" do |env|
challenges = Challenge.all("ORDER BY id DESC")
render "src/challenge/views/challenges/index.ecr", "src/challenge/views/layouts/main.ecr"
end
get "/challenges/:id" do |env|
if challenge = Challenge.find env.params.url["id"]
render("src/challenge/views/challenges/details.ecr", "src/challenge/views/layouts/main.ecr")
else
"Challenge with ID #{env.params.url["id"]} Not Found"
env.redirect "/challenges"
end
end
get "/challenges/new" do |env|
render "src/challenge/views/challenges/new.ecr", "src/challenge/views/layouts/main.ecr"
end
Anyone coming from a traditional web framework that includes an ORM will recognise these routes and the logic as very standard. The final additions to this web app are the routes to render custom templates for authorisation and internal errors:
error 500 do
render "src/challenge/views/error/srv.ecr", "src/challenge/views/layouts/main.ecr"
end
error 401 do
render "src/challenge/views/error/auth.ecr", "src/challenge/views/layouts/main.ecr"
end
Conclusion
The GitHub repo for this completed application can be found here, in the Challenge sample app
Coming from a lower-level programming background, whenever I build a web application, I always take the easiest route, i.e. using a complete framework. With Crystal being such a young language it is to be expected that the equivalent libraries from other languages do not yet exist. When I build a web application, I generally use Rails. Alongside Rails, I would use Devise / Omniauth for authentication and something like Rolify or CanCan for user role management. But with these not yet existing for Crystal, we have had to roll our own.
The above sample app is a basic, yet functional example of a Crystal-based web app that takes a user through authorisation, and role / resource management using JWTs. Dropping in Auth0's hosted login on the frontend allowed us to entirely bypass having to build a User and Password system, or having to keep a users table altogether.
I am incredibly excited to see how the Crystal language and community will continue to grow, and I aim to continue being a part of that community too. Maybe one day soon I'll get the time to write and maintain a modular JWT / Authentication library for Crystal that you can drop into your applications for instant use.
Before I finish, I would just like to quickly send a thank you to Serdar Dogruyol, the creator of the Kemal framework, for his advice on using the Kemal-Session library.
Thanks for sticking with me on what was a long tutorial—I greatly appreciate it!