developers

Add Authorization to a Sinatra API using Auth0

Learn how to implement a Sinatra API and protect its endpoints using Auth0

Carla Urrea Stabile

Senior Developer Advocate

Mar 13, 2023 • 22 min read

Sinatra is one of the most popular Ruby frameworks for developing web applications and APIs, used by over 200K applications. Sinatra is a Domain Specific Language (DSL) for creating web applications and APIs in Ruby; it's not your typical web app Model-View-Controller framework but ties specific URLs directly to relevant Ruby code and returns its output in response.

In this blog post, you'll learn how to build a Sinatra API and protect its endpoints using Auth0. You'll build Sinatra Songs API, a songs CRUD API, and learn about the top songs of Frank Sinatra because there's no Sinatra API without some Frank Sinatra in it! 😉

Project Requirements

For this project, you'll use the following versions:

Try out the most powerful authentication platform for free.

Get started →

You'll build a Sinatra Songs API from scratch, but if you need it, you can check out the project repository, which has two branches. The 

main
branch contains the songs CRUD API, and the 
add-authorization
branch includes the code used to connect with Auth0 and protect your endpoints.

Building the Songs API

Let's start by creating a new project. In your terminal, create a new folder called 

sinatra-auth0-songs-api
and make it your current directory.

Installing Sinatra

Let's go ahead and install Sinatra. First, you'll need to create a 

Gemfile
to handle all your dependencies.

Create a new file, 

Gemfile
, in the root of your project and fill it up with the following: 

# Gemfile 

# frozen_string_literal: true

source 'https://rubygems.org'

ruby File.read('.ruby-version').strip

gem 'sinatra', '~> 3.0', '>= 3.0.2'
gem 'puma'

You can specify the ruby version in the 

Gemfile
; this is a common practice I personally like because as explained in the Bundler docs: This makes your app fail faster in case you depend on specific features in a Ruby VM. This way, the Ruby VM on your deployment server will match your local one.

To do so, you specify a file called 

.ruby-version
and populate it with the Ruby version you'll use, as follows:

3.1.2

Finally, install the gems by running the following: 

bundle install

And just like that, Sinatra 🎩 is installed! You also installed 

puma
as a web server.

Creating the song model

Let's create a class to represent a song. Create a new folder, 

models
, and a new file, 
song.rb
inside the 
models
directory.

Populate the 

song.rb
file with the following code: 

# models/song.rb

# frozen_string_literal: true

# Class to represent a Song
class Song
  attr_accessor :id, :name, :url

  def initialize(id, name, url)
    @id = id
    @name = name
    @url = url
  end

  def to_json(*a)
    {
      'id' => id,
      'name' => name,
      'url' => url
    }.to_json(*a)
  end
end

You are defining a 

Song
class with three attributes: 
id
, 
name
, and 
url
. You are also implementing a more specialized version of the 
to_json
method from Ruby, which will act as a serializer when you render a song as JSON in the controller.

Implement CRUD API

So far, you've only worked with Ruby; now it's time to get hands-on with Sinatra.

Create a new file, 

api.rb
from your terminal and add the following content to the 
api.rb
file, which will serve as a skeleton for the API: 

# api.rb

# frozen_string_literal: true

require 'sinatra'
require 'json'

before do
  content_type 'application/json'
end

get '/songs' do
  return {todo: :implementation}.to_json
end

get '/songs/:id' do
  return {todo: :implementation}.to_json
end

post '/songs' do
  return {todo: :implementation}.to_json
end

put '/songs/:id' do
  return {todo: :implementation}.to_json
end

delete '/songs/:id' do
  return {todo: :implementation}.to_json
end

Let's break down what's going on in the 

api.rb
file.

First, you are requiring the 

sinatra
and 
json
gems. 

require 'sinatra'
require 'json'

Unlike Rails, in Sinatra, you have to load everything yourself. This could be great because it removes all the Rails magic 🔮 by forcing you to be explicit with what you are using.

Next, you are defining a 

before
filter: 

before do
  content_type 'application/json'
end

As explained in the Sinatra Docs, 

before
filters are evaluated before each request.

In this case, you are setting the Content-Type header to 

application/json
, meaning you are making the client aware that all the responses from this server have JSON format.

Next, you define the routes:

get '/songs' do
  # ...
end
get '/songs/:id' do
  # ...
end
post '/songs' do
  # ...
end
put '/songs/:id' do
  # ...
end
delete '/songs/:id' do
  # ...
end

These routes represent the CRUD you'll be implementing.

  • Create: POST 
    /songs
  • Read: GET 
    /songs
  • Read: GET 
    /songs/:id
  • Update: PUT 
    /songs/:id
  • Delete: DELETE 
    /songs/:id

Well, it's more like CRRUD, but you get the point. 🫠

With your API skeleton in place, you can run the server and test the endpoints.

To run the server from your terminal: 

ruby api.rb

Once the server is running, your terminal will look as follows: 

➜  sinatra-auth0-songs-api git:(main) ✗ ruby api.rb 
== Sinatra (v3.0.2) has taken the stage on 4567 for development with backup from Puma
Puma starting in single mode...
* Puma version: 6.0.0 (ruby 3.1.2-p20) ("Sunflower")
*  Min threads: 0
*  Max threads: 5
*  Environment: development
*          PID: 98050
* Listening on http://127.0.0.1:4567
* Listening on http://[::1]:4567
Use Ctrl-C to stop

Now you can access the endpoints on 

http://localhost:4567
. I've created a POSTMAN Collection, so you can test the endpoints yourself. You can also use 
curl
like so:

➜ curl -v http://localhost:4567/songs 
       
{"todo":"implementation"}%

Populate the API with the 
songs.json
file

To have some data in the API, you can download the 

songs.json
file from the repository accompanying this article, which was populated using data from the LastFM API. The 
songs.json
file contains Frank Sinatra's Top 10 Tracks in a simplified version of what LastFM provides with the following format: 

{
  "id": 1,
  "name": "My Way",
  "url": "https://www.last.fm/music/Frank+Sinatra/_/My+Way"
}

Let's implement a helper to read from the 

songs.json
file and load the data once the Sinatra API starts.

Create a new folder, 

helpers
, and a 
songs_helper.rb
inside of it and populate it with the following code: 

# helpers/songs_helper.rb

# frozen_string_literal: true

require_relative '../models/song'
require 'json'

# Class to read songs from a JSON file
class SongsHelper
  def self.songs
    filepath = File.join(File.dirname(__FILE__), '../songs.json')
    file = File.read(filepath)
    data = JSON.parse(file)['songs']

    data.map do |song|
      Song.new(song['id'], song['name'], song['url'])
    end
  end
end

The 

SongsHelper
class implements a 
songs
method that reads the 
songs.json
file and maps its content into an array of 
Song
objects.

Next, in your 

api.rb
file, you can call the 
SongsHelper.songs
function to load the songs:

# api.rb 

# frozen_string_literal: true

require 'sinatra'
require 'json'
# 👇 new code 
require_relative 'helpers/songs_helper'

songs ||= SongsHelper.songs
# 👆 new code 

# existing code ...

You are importing the 

helpers/songs_helper
file, calling the 
songs
method, and storing it in a 
songs
variable.

Note in a real-world app, you'd have a proper database, and there will be no need to do this step, but to keep this tutorial simple, we won't have a database and will work with the data coming from the 

songs.json
file.

Using the 

songs
variable, you can now manage the 
GET songs
request as follows: 

# api.rb 

# frozen_string_literal: true

require 'sinatra'
require 'json'
require_relative 'helpers/songs_helper'

songs ||= SongsHelper.songs

before do
  content_type 'application/json'
end

# 👇 new code 
get '/songs' do
  return songs.to_json
end
# 👆 new code 

# existing code ...

The 

GET songs
request will now retrieve an array of songs, testing it out with 
curl
: 

➜ curl http://localhost:4567/songs 
[
  {"id":1,"name":"My Way","url":"https://www.last.fm/music/Frank+Sinatra/_/My+Way"},
  {"id":2,"name":"Strangers in the Night","url":"https://www.last.fm/music/Frank+Sinatra/_/Strangers+in+the+Night"},
  {"id":3,"name":"Fly Me to the Moon","url":"https://www.last.fm/music/Frank+Sinatra/_/Fly+Me+to+the+Moon"},
  {"id":4,"name":"That's Life","url":"https://www.last.fm/music/Frank+Sinatra/_/That%27s+Life"},
  {"id":5,"name":"I've Got You Under My Skin","url":"https://www.last.fm/music/Frank+Sinatra/_/I%27ve+Got+You+Under+My+Skin"},
  {"id":6,"name":"Come Fly With Me","url":"https://www.last.fm/music/Frank+Sinatra/_/Come+Fly+With+Me"},
  {"id":7,"name":"The Way You Look Tonight","url":"https://www.last.fm/music/Frank+Sinatra/_/The+Way+You+Look+Tonight"},
  {"id":8,"name":"Fly Me to the Moon (In Other Words)","url":"https://www.last.fm/music/Frank+Sinatra/_/Fly+Me+to+the+Moon+(In+Other+Words)"},
  {"id":9,"name":"Theme from New York, New York","url":"https://www.last.fm/music/Frank+Sinatra/_/Theme+from+New+York,+New+York"},
  {"id":10,"name":"Jingle Bells","url":"https://www.last.fm/music/Frank+Sinatra/_/Jingle+Bells"}  
]%

Let's now implement the song details' route, 

songs/:id
. To do so, let's introduce the concept of helpers and implement a new one.

In your 

api.rb
file, add the following content: 

# frozen_string_literal: true

require 'sinatra'
require 'json'
require_relative 'helpers/songs_helper'

songs ||= SongsHelper.songs

# 👇 new code
helpers do
  def id_param
    halt 400, { message: 'Bad Request' }.to_json if params['id'].to_i < 1
    params['id'].to_i
  end
end
# 👆 new code 

# existing code ...

In Sinatra, helpers refer to a top-level method that defines helper methods to use in route handlers and templates.

In this case, you are defining a helper 

id_param
that checks first if the 
params
hash is defined. The 
params
hash is a hash that Sinatra makes available for you in your route blocks, and it will automatically include relevant data from the request.

In the 

id_param
method, you are showing a 
Bad Request
error if the 
params['id']
value is not positive. When it is a valid value, you return it and convert it to an integer. You'll use the 
id_param
method for all the routes that require 
:id
in the route, meaning:

  • GET 
    /songs/:id
  • PUT 
    /songs/:id
  • DELETE 
    /songs/:id

Now, going back to the 

api.rb
file, you can implement the song details route by making use of the 
id_param
helper method as follows:

# existing code ... 

get '/songs' do
  return songs.to_json
end

get '/songs/:id' do
  # 👇 new code
  song = songs.find { |s| s.id == id_param }
  halt 404, { message: 'Song Not Found' }.to_json unless song

  return song.to_json
  # 👆 new code 
end

# existing code ...

You are using Ruby's 

Enumerable#find
method to find the song in the 
songs
array that has the ID sent in the params. If the song was not found, then you'll return a 
404 NOT FOUND
error. Otherwise, you'll return the 
song
in JSON format.

Let's test it out with 

curl
: 

➜ curl http://localhost:4567/songs/1

{"id":1,"name":"My Way","url":"https://www.last.fm/music/Frank+Sinatra/_/My+Way"}%

Noice. At this point, you have implemented both of the read routes from your Songs API. Time to create, update, and delete.

Let's start by the create route. You can create a new song by providing a 

name
and a 
url
. In 
curl
, that POST request will look as follows:

curl -X POST 'http://localhost:4567/songs' \
     -H 'Content-Type: application/json' \
     -d '{
          "name": "A new song",
          "url": "http://example.com"
        }'

You must pass the 

name
and 
url
in the request's body and declare that they come with the correct JSON format. You'll also need to do this when updating a song. This is a hint for you to implement a helper.

Let's implement a new helper, 

json_params
, that will check the body is indeed in JSON format.

In your 

api.rb
, add the following code:

# api.rb

# frozen_string_literal: true

require 'sinatra'
require 'json'
require_relative 'helpers/songs_helper'

songs ||= SongsHelper.songs

helpers do
  # existing code ...
 
  # 👇 new code 
  def json_params
    request.body.rewind
    @json_params ||= JSON.parse(request.body.read).transform_keys(&:to_sym)
  rescue JSON::ParserError
    halt 400, { message: 'Invalid JSON body' }.to_json
  end
  # 👆 new code 

  # existing code ...
end

# existing code ...

The 

json_params
method reads from the 
request.body
and parses it using 
JSON.parse
. If there is a 
JSON::ParseError
, meaning the body was not in JSON format, the method will return 
400 Bad Request
.

You should also validate that the body parameters are only the required ones: 

name
and 
url
. Let's create a new helper that will implement that validation: 

# api.rb

# existing code ...

helpers do
  # existing code ...
 
  def json_params
    request.body.rewind
    @json_params ||= JSON.parse(request.body.read).transform_keys(&:to_sym)
  rescue JSON::ParserError
    halt 400, { message: 'Invalid JSON body' }.to_json
  end
  
  # 👇 new code
  def require_params!
    json_params

    attrs = %i[name url]

    halt(400, { message: 'Missing parameters' }.to_json) if (attrs & @json_params.keys).empty?
  end
  # 👆 new code 

  # existing code ...
end

# existing code ...

The 

require_params!
method will be the main method that you'll use in your routes. Firstly, it calls 
json_params
to initialize the instance variable 
@json_params
and is available in the 
api.rb
context. Then, the 
require_params!
method verifies that 
@json_params.keys
includes any of the values 
name
or 
url
and no other parameter. You can think of it as an attempt of Rails' 
permit
method. Otherwise, it returns 
400 Bad Request
.

The 

name
and 
url
params are only required when creating and updating a song. You can create a 
before
filter to accomplish this.

In your 

api.rb
, add the following:

# frozen_string_literal: true

require 'sinatra'
require 'json'
require_relative 'helpers/songs_helper'

songs ||= SongsHelper.songs

# 👇 new code 
set :method do |*methods|
  methods = methods.map { |m| m.to_s.upcase }
  condition { methods.include?(request.request_method) }
end
# 👆 new code

helpers do
  # ... existing code 
end

before do
  content_type 'application/json'
end

# 👇 new code 
before method: %i[post put] do
  require_params!
end
# 👆 new code

Let's break this down. You added two new things: one is a 

set
and the other is a 
before
filter which you are already familiar with.

The 

set
method takes a setting name and value and creates an attribute on the application.

In this case, you'll use it to identify the HTTP method. The setting name is 

:method
, and it takes an array of symbols as an argument. Then, you use a 
condition
, meaning you want this 
before
filter only to execute when the 
condition
is true, in this case, when the HTTP method is 
POST
or 
PUT
.

In the 

before
filter, you are passing a list of symbols representing the HTTP methods where you want this code to execute, and then you call the 
require_params!
.

Now let's add the code for creating and updating songs in your 

api.rb
.

First, to create a new song, you'll handle the 

POST /songs
request: 

# existing code ...

before method: %i[post put] do
  require_params!
end

# existing code ...

# 👇 new code 
post '/songs' do
  create_params = @json_params.slice(:name, :url)

  if create_params.keys.sort == %i[name url]
    new_song = { id: songs.size + 1, name: @json_params[:name], url: @json_params[:url] }
  else
    halt(400, { message: 'Missing parameters' }.to_json)
  end

  songs.push(new_song)

  return new_song.to_json
end
# 👆new code 

# existing code ...
end
# existing code ...

The 

post /songs
route tries to keep things simple. First, it verifies that both params 
name
and 
url
are present in the 
@json_params
hash; keep in mind the 
require_params!
filter already made sure these are the only parameters being passed. If the 
name
and 
url
are present, you can create a new song. Note you are just incrementing the 
songs.size
value by 1 and then pushing the new song to the 
songs
array. In a real-life application, you would create a new record in your database. If the 
name
or 
url
parameters are missing, then you return a 
400 Bad Request
error.

Let's proceed to add the code for the update route, 

put /songs/:id
: 

# api.rb 
# existing code ... 

# 👇 new code 
put '/songs/:id' do
  song = songs.find { |s| s.id == id_param }

  halt 404, { message: 'Song Not Found' }.to_json unless song

  song.name = @json_params[:name] if @json_params.keys.include? :name
  song.url = @json_params[:url] if @json_params.keys.include? :url

  return song.to_json
end
# 👆new code 

# existing code ...
end

When requested to update a song, your code attempts to find the song in the 

songs
array using the 
id_param
, similar to the song details route. If it's not found, it returns a 
404 Not Found
error. If the song is found, it updates only the field that was sent in the request body and finally returns the song in JSON format.

Last but not least, there is the delete song route, 

delete /songs/:id
. Let's add it to the 
api.rb
file: 

# api.rb 
# existing code ... 

# 👇 new code 
delete '/songs/:id' do
  song = songs.find { |s| s.id == id_param }
  halt 404, { message: 'Song Not Found' }.to_json unless song

  song = songs.delete(song)

  return song.to_json
end
# 👆new code 

# existing code ...
end

The delete song method is very similar to the update song method, but instead, it calls the 

Array#delete
function and renders the song in JSON format as well.

Your Songs API is finished! But not secured 😩. At this point, your code must be very similar to the one on the main branch of the repository.

Protect Your Endpoints with Auth0

Up until here, you have created a CRUD Songs API, but anyone can call any endpoint. You want to make sure only authorized users can create, update, and delete songs.

To achieve this, you'll use Auth0 as your identity access management (IAM) provider.

Note that from this point on, you will be writing the code that is already implemented in the 

add-authorization
branch, so you can use it as a guide.

Connect your Sinatra API with Auth0

Before you jump into the code, you'll need to create a new Auth0 API. Head to the API section of your Auth0 dashboard and click the "Create API" button. Fill out the form with the following values:

  • Name: Sinatra Songs API
  • Identifier: 
    https://sinatra-auth0-songs-api
  • Signing Algorithm: RS256 (this should be the default selection)

Creating a new Auth0 API

Copy the 

identifier
value (
https://sinatra-auth0-songs-api
) — you'll need it when setting up your Sinatra API. You'll also need to grab your Auth0 Domain. Unless you're using a custom domain, this value will be 
[TENANT_NAME].[REGION].auth0.com
. If you're unsure what this value is, open the "Test" tab in your API's settings and look at the 
url
argument in the code sample under "Asking Auth0 for tokens from my application":

finding Auth0 Domain in test section of API

Once you've finished creating your API, you can head to the command line and start installing the dependencies.

Install dependencies

You'll need a few gems, so let's go ahead and add them to the 

Gemfile
: 

gem 'dotenv'
gem 'jwt'

Next, in your terminal, run:

bundle install

You are installing the dotenv gem to read environment variables from a local 

.env
file. You can use the 
.env.example
file from the repository as a template and copy its content to a 
.env
file in the root of your project.

Remember in the previous step; you had to save your Auth0 domain and identifier? Well, this is where you get to use it.

Paste your 

AUTH0_DOMAIN
and 
AUTH0_IDENTIFIER
into your 
.env
file.

You also installed the JWT gem, which is a Ruby implementation of the JWT standard and will help you later on to validate JWT tokens, you'll learn more about those in a bit.

Validate the access token

In order to protect your API's endpoints, you'll use what's called token-based authorization. Basically, your Sinatra Songs API will receive an access token; the passed access token informs the API that the bearer of the token has been authorized to access the API and perform specific actions specified by the scope.

Finally, your API will validate the access token by making sure it has the proper structure and that it was issued by the correct authorization server, in this case, Auth0.

Create an Auth0 Client class

The first step to validate the access token is to create a new class to take care of the process.

In your 

helpers
folder, create a new file called 
auth0_client_helper.rb
and add the following code: 

# helpers/auth0_client_helper.rb

# frozen_string_literal: true

require 'jwt'
require 'net/http'

# AuthoClient helper class to validate JWT access token
class Auth0ClientHelper
  # Auth0 Client Objects
  Error = Struct.new(:message, :status)
  Response = Struct.new(:decoded_token, :error)

  # Helper Functions
  def self.domain_url
    "https://#{ENV['AUTH0_DOMAIN']}/"
  end

  def self.decode_token(token, jwks_hash)
    JWT.decode(token, nil, true, {
                 algorithm: 'RS256',
                 iss: domain_url,
                 verify_iss: true,
                 aud: (ENV['AUTH0_AUDIENCE']).to_s,
                 verify_aud: true,
                 jwks: { keys: jwks_hash[:keys] }
               })
  end

  def self.get_jwks
    jwks_uri = URI("#{domain_url}.well-known/jwks.json")
    Net::HTTP.get_response jwks_uri
  end

  # Token Validation
  def self.validate_token(token)
    jwks_response = get_jwks

    unless jwks_response.is_a? Net::HTTPSuccess
      error = Error.new(message: 'Unable to verify credentials', status: :internal_server_error)
      return Response.new(nil, error)
    end

    jwks_hash = JSON.parse(jwks_response.body).transform_keys(&:to_sym)

    decoded_token = decode_token(token, jwks_hash)
    Response.new(decoded_token, nil)
  rescue JWT::VerificationError, JWT::DecodeError
    error = Error.new('Bad credentials', 401)
    Response.new(nil, error)
  end
end

There are a few things going on in this class, and I've explained it extensively in the Rails API Authorization By Example Guide, particularly the section Validate a JSON Web Token (JWT) in Rails under "What is the Auth0Client class doing under the hood?". Of course, I made a few changes to modify the code from Rails to Sinatra, but the main idea remains.

You can learn more about these security concepts in practice using the Rails Authentication By Example guide and the Rails Authorization By Example guide, which also covers the concept of Role-Based Access Control (RBAC).

With that being said, let's take a look at the main method in this class: the 

validate_token
method. 

def self.validate_token(token)
    jwks_response = get_jwks

    unless jwks_response.is_a? Net::HTTPSuccess
      error = Error.new(message: 'Unable to verify credentials', status: :internal_server_error)
      return Response.new(nil, error)
    end

    jwks_hash = JSON.parse(jwks_response.body).transform_keys(&:to_sym)

    decoded_token = decode_token(token, jwks_hash)
    Response.new(decoded_token, nil)
  rescue JWT::VerificationError, JWT::DecodeError
    error = Error.new('Bad credentials', 401)
    Response.new(nil, error)
  end

Let's break down what the 

validate_token
method is doing:

  1. First, you call the 
    get_jwks
    method, which in summary calls Auth0's 
    well-known
    endpoint and returns the JSON Web Key Set (JWKS) used to verify all Auth0-issued JWTs for your tenant. If there was an error getting the JWKS, then you throw an error because the token could not be validated.
  2. Next, you parse the JWKS into a hash to make it easier to work with in Ruby.

  3. Finally, you call the 

    decode_token
    method, which uses the JWT gem to decode the access token as follows:

    JWT.decode(token, nil, true, {
              algorithm: 'RS256',
              iss: domain_url,
              verify_iss: true,
              aud: (ENV['AUTH0_AUDIENCE']).to_s,
              verify_aud: true,
              jwks: { keys: jwks_hash[:keys] }
            })

The 

domain_url
gets your 
AUTH0_DOMAIN
from the environment variables, and you set your 
AUTH0_AUDIENCE
in the 
aud
value. Finally, you pass the 
jwks_hash
you created earlier in the 
jwks
argument.

To learn more about the 

JWT.decode
arguments, you can refer to the Rails API Authorization By Example Developer Guide, section "What is the Auth0Client class doing under the hood?".

Create an 
authorize!
helper

The 

Auth0ClientHelper
class is already doing most of the work to validate the access token. Now you need to actually call it in the endpoints you want to protect.

For that, you can use a helper, similar to how you used it earlier.

Go to your 

api.rb
file and add the following code:

# api.rb 

# existing code ...

helpers do
  # existing code ... 

  # 👇 new code
  def authorize!
    token = token_from_request

    validation_response = Auth0ClientHelper.validate_token(token)

    return unless (error = validation_response.error)

    halt error.status, { message: error.message }.to_json
  end

  def token_from_request
    authorization_header_elements = request.env['HTTP_AUTHORIZATION']&.split

    halt 401, { message: 'Requires authentication' }.to_json unless authorization_header_elements

    unless authorization_header_elements.length == 2
      halt 401, { message: 'Authorization header value must follow this format: Bearer access-token' }.to_json
    end

    scheme, token = authorization_header_elements

    halt 402, { message: 'Bad credentials' }.to_json unless scheme.downcase == 'bearer'

    token
  end
  # 👆 new code
end

# existing code ...

Well, you actually added two helpers but the 

token_from_request
method is the helper of the 
authorize!
helper 😛.

The 

authorize!
helper gets the token from the request by calling the 
token_from_request
method. This method checks the 
HTTP_AUTHORIZATION
header and splits it to verify it is well-formed.

A well-formed 

Authorization
header using the bearer scheme looks like this: 

Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdCI6MTUxNjIzOTAyMn0.NHVaYe26MbtOYhSKkoKYdFVomg4i8ZJd8_-RU8VNbftc4TSMb4bXP3l3YlNWACwyXPGffz5aXHc6lty1Y2t4SWRqGteragsVdZufDn5BlnJl9pdR_kdVFUsra2rWKEofkZeIC4yWytE58sMIihvo9H1ScmmVwBcQP6XETqYd0aSHp1gOa9RdUPDvoXQ5oqygTqVtxaDr6wUFKrKItgBMzWIdNZ6y7O9E0DhEPTbE9rfBo6KTFsHAZnMg4k68CDp2woYIaXbmYTWcvbzIuHO7_37GT79XdIwkm95QJ7hYC9RiwrV7mesbY4PAahERJawntho0my942XheVLmGwLMBkQ

Then, the 

token_from_request
method verifies if the 
Authorization
header is present, if the token is present, and if it has the correct scheme. Otherwise, it will return 
401 Unauthorized
.

Once the token is retrieved from the 

Authorization
header, the 
authorize!
helper calls the 
validate_token
method of the 
Auth0ClientHelper
class to validate the token. If the token was validated without errors, the 
authorize!
method finished its execution. If there is any error during the validation, it returns it with a proper status and message.

Protect your API endpoints with the 
authorize!
helper

The last step to protect your endpoints is to call the 

authorize!
helper before any client tries to call them.

So as you saw earlier, a 

before
filter is the way to go.

In your 

api.rb
file, you already had a 
before
filter that you can reuse, so let's modify it:

# api.rb 
# existing code ... 

# old code
# before method: %i[post put] do
#   require_params!
# end
# old code

# 👇 new code
before method: %i[post put delete] do
  require_params!
  authorize!
end
# 👆 new code
# existing code ...

First, you added the 

delete
method to the 
before
filter because you want only authorized users to be able to create, update and delete songs.

Then you call the 

authorize!
helper that will perform the authorization validation.

That's it! You can now test your endpoints with 

curl
as follows: 

curl -X POST 'http://localhost:4567/songs' \
-H 'Authorization: Bearer YOUR_TOKEN' \
-d '{
    "name": "A new song"
    "url": "http://example.com"
}'

Once you replace the 

YOUR_TOKEN
placeholder with a valid access token, the result of this request will be the following:

{"id":11,"name":"A new song","url":"http://example.com"}

To get a valid access token for your API, follow the steps shown in the section Connect your Sinatra API With Auth0.

Summary

In this blog post, you learned about the Ruby framework Sinatra and how to create a basic CRUD API to manage Frank Sinatra songs.

You created a new Auth0 account and a new API from the dashboard. You used the JWT gem to validate an access token issued by Auth0 and finally secured your API endpoints for creating, updating, and deleting songs by using token-based authorization and the bearer scheme.

I hope you enjoyed this post. Do you use any other Ruby frameworks? Let me know in the comments!

Thanks for reading!