carla_urrea

I've been working as a software engineer since 2014, particularly as a backend engineer and doing system design. I consider myself a language-agnostic developer but if I had to choose, I like to work with Ruby and Python.  

After realizing how fun it was to create content and share experiences with the developer community I made the switch to Developer Advocacy. I like to learn and work with new technologies. 

When I'm not coding or creating content you could probably find me going on a bike ride, hiking, or just hanging out with my dog, Dasha. 

Staff Developer Advocate

Carla Urrea Stabile

The way to implement an authorization system depends on your application's needs. Let's explore Relationship-Based Access Control (ReBAC) and implement it in a Rails API using OpenFGA.

How to Implement Relationship-Based Access Control (ReBAC) in a Ruby On Rails API?

There are different ways to implement an authorization system and the one you choose depends on your application's needs. Attribute-Based Access Control (ABAC) is just one of them, so let's go ahead and learn how to implement it in a Rails API.

Previously on your access control series \*read with TV show presenter's voice\*... You learned about [Role-Based Access Control (RBAC) and how to integrate it into your Rails API](https://auth0.com/blog/what-is-rbac-and-how-to-implement-it-rails-api/).
In this blog post, you’ll continue learning about different authorization systems, this time about Attribute-Based Access Control and how to migrate the access control of the expense management API from RBAC to ABAC. 

<details>
<summary>Starting from here?</summary>

If you want to start this tutorial from the beginning, [start from this blog post.](https://auth0.com/blog/what-is-rbac-and-how-to-implement-it-rails-api/)

Clone the application repo and check out the `add-rbac` branch:

``` bash  
git clone -b add-rbac https://github.com/auth0-blog/rails-api-authorization 
```

Make the project folder your current directory:

``` bash  
cd rails-api-authorization
```

Then, install the project dependencies:

``` bash  
bundle install
```

Then, setup the database

``` bash
  rails db:setup
```

Finally, create a `.env` hidden file:

``` bash  
touch .env
```

Populate `.env` using the `.env.example` file:

``` bash  
cp .env.example .env
```

Add your Auth0 configuration variables to the .env file and run the project by executing the following command:

``` bash  
rails s
```

</details>

## What Are Attributes in the Context of Access Control?

Let's consider the use case of the expense management API you are using in this tutorial. For RBAC, you created an `admin` role and assigned it to users using Auth0 Actions. Users with the `admin` role can approve and review expenses, and so far, that's so good. 

The following requirement you have is that only certain users can do certain things on specific expense reports: 

- Users can only see a report they own (submitted by them)
- Users can only see a report if they are the approver
- Users who are approvers can only *approve* reports on weekdays (we don't want people working on weekends!)

With the current RBAC implementation, a user with the `admin` role can do all of these things, but unfortunately, not all admin users need to approve reports. So, as a solution, you think adding these guards to your code sounds good, so **you are going to check the attributes of the report** (the user is either the approver or submitter of this report), the date the report is being approved, etc. 

This practice has a name, and it's called Attribute-Based Access Control.

## What Is Attribute-Based Access Control (ABAC)?

[According to NIST, Attribute-Based Access Control (ABAC)](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-162.pdf) is an access control method where a subject's requests to perform operations on objects are granted or denied **based on assigned attributes of the subject, assigned attributes of the object**, environment conditions, and a set of policies that are specified in terms of those attributes and conditions.

In other words, any access decision that your application makes based on attributes of an entity can be considered ABAC and it'll be specific to your application and access control needs. 

ABAC also gives you more control and granularity over your access decisions, making it more flexible than RBAC. 

Regarding the expense management API, RBAC and ABAC can coexist; in fact, checking for a role or permission is also checking for attributes, in this case, attributes assigned to the user, so we can say RBAC is an implementation of ABAC with a limited scope of roles and permissions. So now, let's say it is a requirement that the user also needs to be an admin to perform the approver actions. Why not? 😛 

Let's look at what you'll need to change in your Ruby on Rails API to comply with the new access control requirements and implement ABAC. 

## ABAC Implementation in a Ruby on Rails API

Let's take a look at the requirements you need to implement: 

- Users can only see a report they own (submitted by them)
- Only approvers can see reports submitted by other users
- Only admin users can approve reports
- Users who are approvers can only *approve* reports on weekdays (we don't want people working on weekends!)

Based on this, there are a few changes you could make to the application; most of them are related to the `report` entity. 

Let's think of the scenario where a **user can only see a report they have submitted, or they are the approver**; you could think of this as multiple things like the user needs to have some relationship with the expense report, meaning they are either the submitter or the approver.

There's little we can do with the relationship example now. Still, you can define that if a user is the submitter or approver of a report, they have some **ownership** over it and are allowed to see that report, so let's start there. 

In the API context, you can define this ownership such that **the user making the request is the same user for which we want to see reports.** At the moment, your API doesn't have the context of the user other than an access token, which tells you only that they are authorized to access your API and that they are `admin` because [you added this role as a custom claim in the access token.](https://auth0.com/blog/what-is-rbac-and-how-to-implement-it-rails-api/#Creating-and-Assigning-Roles-with-Auth0)

So, that's great 🫠 how can you get information from the user in your API using Auth0? The answer is by connecting your Auth0 API and your Auth0 Application!

### Connect Your Auth0 API with your Auth0 Application 

If you have a REST API as your backend, chances are you have a frontend application where your users authenticate and manage their data, etc. 

When you use Auth0, your users can authenticate using [Universal Login](https://auth0.com/docs/authenticate/login/auth0-universal-login). So, you need to create an Auth0 Application for either a SPA or a Regular Web Application and [integrate it with your code using one of the SDKs](https://auth0.com/docs/libraries). For this blog post, let's focus on the example of the regular web application. 

[When you created the expense management API](https://auth0.com/blog/what-is-rbac-and-how-to-implement-it-rails-api/#Building-the-Starter-Application), you created an [Auth0 API](https://auth0.com/docs/get-started/apis) and an Auth0 Regular Web Application for testing purposes, well now you are going to use this Regular Web Application because in a real-life scenario, your users will probably authenticate themselves *somewhere* and once they're authenticated you proceed to do X or Y in your REST API. 

In the Regular Web Application you created in Auth0 for your users to authenticate, you need to implement login, logout, etc., and you can learn how to do so by following [any of the Developer Center Guides on Authentication](https://developer.auth0.com/resources/guides?type=web-app). Still, the general process is almost identical in all of them, and the outcome is that **you will get an access token from Auth0 issued for the authenticated user.** 
 
Then, you need to tell your Regular Web Application that your users will be interacting with your REST API and, therefore, its counterpart in Auth0, so when you request the access token, you need to provide the `audience` as well. An example of how to do this in a [Ruby on Rails Web application](https://developer.auth0.com/resources/guides/web-app/rails/basic-authentication) would be: 

```ruby
Rails.application.config.middleware.use OmniAuth::Builder do
 provider(
 :auth0,
    AUTH0_CONFIG['auth0_client_id'],
    AUTH0_CONFIG['auth0_client_secret'],
    AUTH0_CONFIG['auth0_domain'],
 callback_path: AUTH0_CONFIG['auth0_callback_path'],
 authorize_params: {
 scope: 'openid profile email',
 audience: 'https://rails-api-authorization', # pass the audience ✨
 }
 )
end
```

Once you pass the `audience`, you'll get a JWT token containing the information about the user, as well as any scopes and claims you've added. To learn more about the audience parameter [you can check out this post.](https://community.auth0.com/t/what-is-the-audience)

That's all you need to do for now in Auth0 to make this work, so let's get back to the code!

### Validate Ownership of the User Making the Request

You already added a method to check for the user's role, so similarly, you could do the same to check for the user's *ownership*. In the context of the expense management app, we'll say: 

> A user is allowed to see an expense report of another user if they are the subject of the access token 

At the moment, you do not store any information about the user's data in your database, but you will need the Auth0 user's ID to compare it. 

#### Add the Auth0 ID to the User Model

Let's create a migration to add a new field to the User model using the following command on your terminal: 

```bash
rails g migration AddAuth0IDToUsers auth0_id:string 
```

The command above will generate a new migration file under `db/migrate/YYYYMMDDHHMM_add_auth0_id_to_users.rb` that looks like this:

```ruby
class AddAuth0IdToUsers < ActiveRecord::Migration[7.0]
  def change
 add_column :users, :auth0_id, :string
  end
end
```

Then, execute the migration by running `rails db:migrate` on your terminal. 

Now, let's add a validation to the User model to make sure the `auth0_id` field is always present and unique. Go to `app/models/user.rb` and add the following code: 

```ruby
class User < ApplicationRecord
 has_many :expenses, foreign_key: :submitter_id
 has_many :submitted_reports, class_name: 'Report', foreign_key: 'submitter_id'
 has_many :reports_to_review, class_name: 'Report', foreign_key: 'approver_id'

 validates :email, format: { with: URI::MailTo::EMAIL_REGEXP }, presence: true, uniqueness: true
  # 👇 new code 
 validates :auth0_id, presence: true, uniqueness: true
end
```

You're all set from the model level. Let's move to the controller level. 

#### Add the Ownership Validation to the Controller

Go to the `Secured` concern in `app/controllers/concerns/secured.rb` and add the following code: 

```ruby
# frozen_string_literal: true

module Secured
  extend ActiveSupport::Concern

  REQUIRES_AUTHENTICATION = { message: 'Requires authentication' }.freeze
  BAD_CREDENTIALS = {
 message: 'Bad credentials'
 }.freeze
  MALFORMED_AUTHORIZATION_HEADER = {
 error: 'invalid_request',
 error_description: 'Authorization header value must follow this format: Bearer access-token',
 message: 'Bad credentials'
 }.freeze
  INSUFFICIENT_ROLES = {
 error: 'insufficient_roles',
 error_description: 'The access token does not contain the required roles',
 message: 'Permission denied'
 }.freeze
  # 👇 new code 
  NOT_OWNER = {
 error: 'not_owner',
 error_description: 'The access token does not belong to the current user',
 message: 'Permission denied'
 }.freeze
  # 👆 new code 

  def authorize
 token = token_from_request

 validation_response = Auth0Client.validate_token(token)

    @decoded_token = validation_response.decoded_token

    return unless (error = validation_response.error)

 render json: { message: error.message }, status: error.status
  end

  def validate_roles(roles)
    raise 'validate_roles needs to be called with a block' unless block_given?
    return yield if @decoded_token.validate_roles(roles)

 render json: INSUFFICIENT_ROLES, status: :forbidden
  end

  # 👇 new code 
  def validate_ownership(current_user)
    raise 'validate_ownership needs to be called with a block' unless block_given?
    return yield if @decoded_token.validate_user(current_user)

 render json: NOT_OWNER, status: :forbidden
  end
  # 👆 new code 

  private
  # ... 
end
```

You are adding a new hash called `NOT_OWNER` to specify the error message in case the user is not the owner of the access token being passed. Then, in the `validate_ownership` method, you're checking the access token and returning an error if the user is not the owner. Since you haven't implemented the `validate_user` method yet, let's add it to the token structure. 

Go to your `Auth0Client` class in `app/lib/auth0_client.rb` and add the following code: 

```ruby
# frozen_string_literal: true

require 'jwt'
require 'net/http'

class Auth0Client

  # Class members
  Response = Struct.new(:decoded_token, :error)
  Error = Struct.new(:message, :status)
  Token = Struct.new(:token) do
    def validate_roles(roles)
 required_roles = Set.new roles
 token_roles = Set.new token[0][Rails.configuration.auth0.roles]
 required_roles <= token_roles
    end
    # 👇 new code
    def validate_user(current_user)
 current_user.auth0_id == token[0]["sub"]
    end
    # 👆 new code
  end

  # Helper Functions
  # ...
end
```

The `validate_user` method checks the `current_user` variable (the user from whom you want to check the reports) against the owner of the access token. In the access token, you have information about the user's ID in Auth0 under the `sub` field, so you are comparing that against the `auth0_id` from the local database. 

Next, call the `validate_ownership` method in the `ReportsController`. You want to validate the user's ownership when they request to review or submit a report, so let's add the validation to the corresponding actions. 

Go to `app/controllers/reports_controller.rb` and add the following code: 

```ruby
class ReportsController < ApplicationController
 before_action :set_report, only: %i[ show approve ]
 before_action :set_user
 before_action :authorize

  # GET users/:user_id/reports/submitted
  def submitted
    # 👇 new code
 validate_ownership(@user) do # user is the owner of these reports
      @reports = Report.where(submitter_id: @user.id) # list only reports where user is submitter

 render json: @reports
    end
    # 👆 new code
  end

  # GET users/:user_id/reports/review
  def review
    # 👇 new code
 validate_ownership(@user) do # user is the owner of these reports
      @reports = Report.where(approver_id: @user.id) # list only reports where user is approver

 render json: @reports
    end
    # 👆 new code
  end

  # GET users/:user_id/reports/1/approve
  # ...
end
```

By adding the `validate_ownership` block in the controller together with the condition inside the query, you are implementing a form of ABAC because you're allowing or denying access based on certain attributes of the user or the report. 

### Validate that Only Approver Users can Approve Reports 

Even though this might be a new requirement, you already took care of this scenario when you first added RBAC. If you look at the `approve` action in the `ReportsController`:

```ruby
class ReportsController < ApplicationController
 before_action :set_report, only: %i[ show approve ]
 before_action :set_user
 before_action :authorize

  # GET users/:user_id/reports/submitted
  # ...

  # GET users/:user_id/reports/1/approve
  def approve
 validate_roles [ADMIN] do # if user is admin
      if @report.is_approver?(@user) # if user is the approver for this report
        @report.status = "approved"
        @report.save
 render json: @report
      end
    end
  end

  # GET users/:user_id/reports/1
  #...
end
```

The check for `@report.is_approver?(@user)` already confirms that 
 `@user` is the approver of `@report`. This is interesting because sometimes we mix up different authorization models without even realizing it, and that's okay as long as it fits your business model. s

### Validate that Approvals Only on Weekdays

You only have to add another validation to allow users to approve expense reports on weekdays, and this is possible by adding a new check to the `approve` action in the `ReportsController`. Go to `app/controllers/reports_controller.rb` and add the following code: 

```ruby
class ReportsController < ApplicationController
 before_action :set_report, only: %i[ show approve ]
 before_action :set_user
 before_action :authorize

  # GET users/:user_id/reports/submitted
  #...

  # GET users/:user_id/reports/1/approve
  def approve
 validate_roles [ADMIN] do # if user is admin
      if @report.is_approver?(@user) # if user is the approver for this report
        # 👇 new code 
        if Date.current.on_weekday? # can only approve on weekdays
          @report.status = "approved"
          @report.save
 render json: @report
        else
 render json: {message: "Can only approve on weekdays"}, status: 401
        end
        # 👆 new code 
      end
    end
  end

  # GET users/:user_id/reports/1
  #...
end
```

[The function `Date.current.on_weekday?`](https://api.rubyonrails.org/classes/DateAndTime/Calculations.html#method-i-on_weekday-3F) returns true if it's a weekday (Mon-Fri) and false otherwise. Users who try to approve during the week will get an error.

At this point, you've fulfilled all the requirements you've received so far! 🚀 It's time to go back to the client and discuss the progress you've made. 

> Up until here, all the changes in the code are available in the [`add-abac` branch of the repository.](https://github.com/auth0-blog/rails-api-authorization/tree/add-abac)

## What About Policies?

You're introducing a lot of extra complexity in the application code that needs to be recreated by each environment, such as web, mobile, CLI, etc. Using a policy engine can streamline application decision-making. 

[A policy](https://csrc.nist.gov/glossary/term/access_control_policy) is a set of rules defining a software service's behavior. There are access control systems like [Open Policy Agent (OPA)](https://www.openpolicyagent.org/), a full-featured policy engine that offloads policy decisions from your software so you don't have to implement it from scratch, or [Policy-Based Access Control (PBAC)](https://csrc.nist.gov/glossary/term/policy_based_access_control), where access control decisions are made based on the business roles of users and is combined with policies.

You won't implement PBAC for the sake of this tutorial, but I thought it was interesting for you to know that decision-making engines like these exist.

## Oh, No. What's Next?

You are showing your implementation to the client, and they're satisfied, but as usual, they came back with more requirements 🥲 

- Users who are managers can see the reports of their directs, plus the reports of their directs' directs, and so on 😵‍💫

You think of a way to implement this with your current solution and... recursiveness 🥲 you know this is possible, but you also start exploring what options are out there for these scenarios. You bump into Relationship-Based Access Control, which seems interesting 🤔 because you feel like basing your implementation on the relationships of your users could work, but you need to do more research. 

## Conclusion 

When we talk about attributes, we refer to properties of the entities of your application; in the expense management application example, we are talking about attributes of a user or an expense report. Attribute-Based Access Control is an authorization model that allows you to make decisions based on these attributes. ABAC gives you more granularity than RBAC because you can specify access control on specific resources other than a role that usually includes more than one resource. 

In the next blog post, you'll learn about ReBAC and its implementations. 

How to Implement Attribute-Based Access Control (ABAC) in a Ruby On Rails API?

There are different ways to implement an authorization system and the one you chose depends on your application's needs. Role-Based Access Control (RBAC) is just one of them, so let's go ahead and learn how to implement it in a Rails API.

How to Implement Role-Based Access Control (RBAC) in a Ruby On Rails API?

People are saying Ruby is dead, while others use it widely in their companies. Let's dive into the history of Ruby. From its birth to how it's doing today and to what the future holds.

[Ruby](https://en.wikipedia.org/wiki/Ruby_(programming_language%29) is an interpreted, open-source programming language with a focus on simplicity and productivity. **Ruby is already 30 years old**, and it has become one of the most used programming languages. 

Some claim Ruby is dead; others use it widely in their companies. Join me in this blog post as we learn about Ruby's history and where it stands today. 

## How It Started

[Ruby was born on Feb. 24th, 1993](https://youtu.be/gTNC26BtRFc?t=85). This was the day when [Yukihiro Matsumoto](https://en.wikipedia.org/wiki/Yukihiro_Matsumoto), also known as **Matz** and creator of Ruby, decided along with his colleague Keiju Ishitsuka what the name of the language was going to be during a chat conversation: 

```plain-text
matz> Let us decide the codename now
matz> tentative one.
keiju> Ok.  
matz> What is your best up to now?
keiju> I'm content with coral.  
matz> I thought ruby is cool as a codename, isn't it
keiju> Well. Ruby is also good.  
matz> But, coral is also good
matz> arrr
```
<center>*[Extract from the chat between Matz and Keiju back in Feb 1993](https://blade.ruby-lang.org/ruby-talk/88819)*</center>
<br/><br/>

They knew they wanted to name the programming language after jewels, so they were considering *Ruby* and *Coral*. As Matz explains in his talk [Ruby After 25 Years](https://youtu.be/gTNC26BtRFc?t=286), Coral was longer by one character making it more annoying to write multiple times. *Ruby was shorter and more beautiful*.

Matz created Ruby because he wanted a simple object-oriented, easy-to-use scripting language. He added the features he loved the most, such as iterators, exception handling, and garbage collection. 

Ruby is a clean, simple, and powerful object-oriented programming language. There are no curly braces; scopes are clearly defined by blocks, and overall makes you happy to use it. This was, in fact, one of Matz's goals when creating the language:

> "I hope to see Ruby help every programmer in the world to be productive, enjoy programming, and be happy. That is the primary purpose of Ruby language."
&mdash; <cite>[Matz on Ruby 1.9, Google TechTalks 2008](https://youtu.be/oEkJvvGEtB4?t=1795)</cite>

I mean, look at this thing: 

```ruby
class Numeric
  def plus(x)
    self.+(x)
  end
end

y = 5.plus 6
# y is now equal to 11
```

I can't imagine a more beautiful thing 🤩. 

This code creates a new class, `Numeric`, with a `plus` method. Because everything is an object in Ruby, you can call this method with anything, even a number! We do this in the example `y = 5.plus 6`. The `Numeric` class is just a small example of what Ruby can do, but I'm sure it gives you an idea of its power.  

But Ruby has come a long way from the first version to the current one. After naming the language in 1993, `ruby-0.95` was released to the Japanese domestic newsgroups on Dec. 21st, 1995. In 1996 `ruby-1.0` was released, and in July 1997, Matz announced that **he had been hired by [netlab.jp](https://www.netlab.jp/), a Japanese open source company, to be a full-time Ruby developer**. This only helped accelerate the implementation of Ruby, so on Aug. 13th, `ruby-1.1` was released, and on Sept. 22nd, 1997, the first article about Ruby was published. I did my best to find it, but it is not available anymore 😭.

The popularity of Ruby was growing every day in Japan, and as more and more developers started to use Ruby, the first Ruby books were published to support the community's continued learning. The first was "The Object-Oriented Scripting Language Ruby" by Matz himself.

![The Object-oriented Scripting Language Ruby 1999 edition book cover](https://images.ctfassets.net/23aumh6u8s0i/5qtUsDS2rpmpR3AIZABxgc/f06c643901227a3a2fb449223415aba9/amazon-ruby-book.jpg)


In 2000 [Ruby was more popular than Python in Japan](http://ruby-doc.com/docs/ProgrammingRuby/html/foreword.html), and the acceptance and growth of the language were starting. In 2004, a new server-side web application framework was born: [Ruby on Rails](https://rubyonrails.org/). The launch of Rails, together with the fact that [Apple announced that it would ship Ruby on Rails with Mac OS X v10.5 "Leopard"](https://rubyonrails.org/2006/8/7/ruby-on-rails-will-ship-with-os-x-10-5-leopard) helped Ruby to become the [Language of the Year in 2006](https://www.tiobe.com/tiobe-index/ruby/) and to be used mainly for web development. 

Fast-forward to 2016, Ruby reaches the highest position (since 2001) in the TIOBE index at number 8, and its usage is peaking. Between 2013 and 2020, we went from `ruby2.0.0` to `ruby3.0.0`, and the community and the language were more and more mature. 

But where is Ruby now? 

## How It's Going 

Ruby is at version [`ruby3.2.1`](https://github.com/ruby/ruby/releases/tag/v3_2_1) as of the date of publishing this article, and by the end of 2022, there were [2.4 million Ruby developers](https://www.slashdata.co/free-resources/state-of-the-developer-nation-23rd-edition?) out there.

At the beginning of this article, I mentioned that some people say Ruby is dying, and I'm afraid I have to disagree with this statement. Ruby, as technology, still creates value nowadays, which is essential to remember. When technology creates value, it also creates jobs, opportunities, and money. 


Now let me tell you why Ruby is still creating value:

### Ruby lives to its purpose: *programmer happiness*

You can take it from me, or you can take it from [other people in the industry.](https://jetrockets.com/blog/is-ruby-still-alive-in-2023) The reality is programming in Ruby is truly joyful, and if you still need to do it, I highly recommend you try it. 

<div class="alert alert-info alert-icon">
  <i class="icon-budicon-487"></i>
<strong>We have created step-by-step guides to help you integrate Auth0 with your Ruby on Rails application. Check out the 
<a onclick="window.metricsLib.track('from_blog_to_devres')" href="https://developer.auth0.com/resources/guides/web-app/rails/basic-authentication">Rails Authentication By Example</a> and the <a onclick="window.metricsLib.track('from_blog_to_devres')" href="https://developer.auth0.com/resources/guides/api/rails/basic-authorization">Rails Authorization By Example</a> guide, which also covers the concept of <a onclick="window.metricsLib.track('from_blog_to_devres')" href="https://developer.auth0.com/resources/guides/api/rails/basic-authorization#set-up-role-based-access-control-rbac">Role-Based Access Control (RBAC)</a> and let yourself fall in love with Ruby😍.</strong>
</div>

### Ruby is widely used in big companies 🧑‍💻

[Ruby is widely used in the tech industry](https://toprubycompanies.info/) by some of the biggest companies like Airbnb, Shopify, Coinbase, and Gitlab. Some are significant contributors to Ruby's source code and Ruby on Rails. 

### Ruby makes money 🤑

In 2022, Ruby and Ruby on Rails are still listed as [the top-paying technologies](https://survey.stackoverflow.co/2022/#top-paying-technologies) for developers, with a median yearly salary of about $90,000. 

Also, because big publicly-traded companies are using Ruby, [the total market cap of only 46 (!) of them is currently at about $284 Billion.](https://toprubycompanies.info/)

### Ruby has a great community

The [Ruby community](https://www.ruby-lang.org/en/community/) is highly active, and many projects contribute to it. One of them is the [Rails Foundation](https://rubyonrails.org/foundation) which aims to improve the documentation, education, marketing, and events to benefit all new and existing Rails developers. 

Also, Ruby is open source, and everyone can contribute to its development; this also means it can quickly evolve to fit developers' needs in the future. 

## What’s Next?

[Ruby 3.0](https://www.ruby-lang.org/en/news/2020/12/25/ruby-3-0-0-released/) was released in 2020 with many improvements and new features, so the plan to keep improvement remains. 

Some of the improvements, ambitions, and features that Ruby will be working on are the following: 

- **Ruby 3x3**: 
  - It started as "Make Ruby 3.0 run 3 times faster than Ruby 2.0", but it [has been revisited in 2021](https://youtu.be/Dp12a3KGNFw?t=2757) and changed to *"Ruby 3.x will be 3 times faster than Ruby 3.0 "* so we will see more and more performance improvements!
- **Performance**: 
  - Ruby 3.2 adds a lot of performance improvements, such as re-implementing the [MJIT](https://www.rubyguides.com/2018/11/ruby-mjit/) compiler in Ruby and executing it under a forked process instead of using a native thread. 
  - [YJIT](https://github.com/ruby/ruby/blob/master/doc/yjit/yjit.md) is now production-ready, and there will be more performance improvements coming as shown by [Alan Wu in RubyKiagi 2022](https://youtu.be/EMchdR9C8XM?t=1910).
- **Concurrency / Parallelism**:
  - Ruby 3.0 introduced [Ractors](https://ruby-doc.org/core-3.0.0/Ractor.html), an [actor-model abstraction](https://en.wikipedia.org/wiki/Actor_model) that provides a parallel execution feature without thread-safety concerns. Ractors have improved since they were first released and will continue their development to ensure Ruby is more *thread-safe* than ever. 
- **Static Analysis with [RBS](https://github.com/ruby/rbs) and [Typeprof](https://github.com/ruby/typeprof)**: both of these tools were released with Ruby 3.0 are still being improved in new versions. 
  - RBS allows you to add type annotations to your Ruby code in files with a new extension called `.rbs`.
  - Typeprof is a type analysis tool that reads plain (non-type-annotated) Ruby code, analyzes what methods are defined and how they are used and generates a prototype of type signature in RBS format.

## Conclusion 

Ruby is an object-oriented and interpreted programming language created by Yukihiro Matsumoto in 1993. Ruby was quickly adopted in Japan and then expanded to the rest of the world; it gained popularity when the Ruby on Rails framework was released. Ruby has peaked in popularity over the years and remained relatively stable. 

Ruby is still widely used in big companies like Shopify, AirBnb, and Github, which also contribute to the source code and investment and language development. 

Programming languages' popularity and the features that developers seek come and go. A few years ago, developers didn't want to deal with static typing; now, they do, for example. It is hard to predict whether Ruby will become extremely popular, but surely Ruby is still alive, and it will live as long it continues to create value for the community and companies but also while it makes developers happy. 

A Brief History of Ruby

square-2

I develop software for a living, and then I go home and continue thinking about software because I just can’t get enough. I’m a full-stack engineer with infrastructure skills. I’ve led multiple agile delivery teams, being an individual contributor, driving architecture topics, and coaching and supporting other team members.<br>
I believe in high-quality software and advocate for Continuous Delivery, Test-Driven Development, and quick iteration. I <a href="https://hceris.com/blog">write</a> and <a href="https://hceris.com/talks">speak</a> about my experience regularly. Needless to say, all the opinions expressed in this blog are mine and only mine.

Staff Engineer

Mario Fernandez

Learn how to secure a Rails API with Auth0 by letting you drive by tests.

How to Add Authorization to a Rails API Following TDD

Learn about five different Ruby gems used for authentication and authorization and when to use them.

If you have built a web application, you most likely had to implement user registration, login, and logout and have restricted access to resources depending on the user. This is what authentication and authorization deal with. There are many ways to implement this in Ruby, and they all have pros and cons. In this post, you'll learn about five different gems you can use to implement authentication and authorization in your Ruby application.

## Authentication vs. Authorization

Before you jump into the gems, you must understand the [difference between authentication and authorization](https://auth0.com/intro-to-iam/authentication-vs-authorization/) because they are commonly confused.

**Authentication is proving if someone or something is who they say they are, while authorization checks if something or someone has access to a particular resource and is allowed to perform a specific action.**

One of the reasons these two concepts get misused is because, usually, authentication has to happen first for authorization to occur. You could need to verify a user's identity to determine whether or not they have access to a particular resource.

With these concepts in your mind now, let's head up to the gems.

<div class="alert alert-info alert-icon">
  <i class="icon-budicon-487"></i>
<strong>You can see these security concepts in practice using the <a onclick="window.metricsLib.track('from_blog_to_devres')" href="https://developer.auth0.com/resources/guides/web-app/rails/basic-authentication">Rails Authentication By Example</a> guide and the <a onclick="window.metricsLib.track('from_blog_to_devres')" href="https://developer.auth0.com/resources/guides/api/rails/basic-authorization">Rails Authorization By Example</a> guide, which also covers the concept of <a onclick="window.metricsLib.track('from_blog_to_devres')" href="https://developer.auth0.com/resources/guides/api/rails/basic-authorization#set-up-role-based-access-control-rbac">Role-Based Access Control (RBAC)</a>.</strong>
</div>

## Authentication Gems 

### Devise

[Devise](https://github.com/heartcombo/devise) is an **authentication gem for Rails** based on [Warden](https://github.com/wardencommunity/warden), a Rack authentication framework that is based on the modularity concept of only using what you need. Devise is an MVC solution based on Rails engines; it allows you to have authentication on multiple models, meaning you could, for example, have a `User` model and an `Admin` model, and they will have different controllers and routes to login, logout, etc. 

Because Devise is so heavily based on Rails, it is recommended you have some Rails knowledge before jumping in and using it.

To get it to work in your app, you need to add it to your Gemfile and [follow the installation steps from their documentation](https://github.com/heartcombo/devise#getting-started). Finally, you can create a new model; let's say you want to call it `User`, for you'll need to run:

```bash
rails generate devise User
```

The above command will create the model, and the migration, which, when you run `rails db:migrate` looks as follows: 

```bash
== 20221020152252 DeviseCreateUsers: migrating ================================
-- create_table(:users)
   -> 0.0009s
-- add_index(:users, :email, {:unique=>true})
   -> 0.0003s
-- add_index(:users, :reset_password_token, {:unique=>true})
   -> 0.0002s
== 20221020152252 DeviseCreateUsers: migrated (0.0015s) =======================
```

The migration creates a new `User` table and adds a few indexes to the table, such as a unique index for the `email` and the `reset_password_token` without you having to do much else. 

It will also generate all the necessary routes for you to handle sign-up, login, logout, and even password-set flows:

```bash
➜  five-gems git:(main) ✗ rails routes
                  Prefix Verb   URI Pattern                    Controller#Action
        new_user_session GET    /users/sign_in(.:format)       devise/sessions#new
            user_session POST   /users/sign_in(.:format)       devise/sessions#create
    destroy_user_session DELETE /users/sign_out(.:format)      devise/sessions#destroy
       new_user_password GET    /users/password/new(.:format)  devise/passwords#new
      edit_user_password GET    /users/password/edit(.:format) devise/passwords#edit
           user_password PATCH  /users/password(.:format)      devise/passwords#update
                         PUT    /users/password(.:format)      devise/passwords#update
                         POST   /users/password(.:format)      devise/passwords#create
cancel_user_registration GET    /users/cancel(.:format)        devise/registrations#cancel
   new_user_registration GET    /users/sign_up(.:format)       devise/registrations#new
  edit_user_registration GET    /users/edit(.:format)          devise/registrations#edit
       user_registration PATCH  /users(.:format)               devise/registrations#update
                         PUT    /users(.:format)               devise/registrations#update
                         DELETE /users(.:format)               devise/registrations#destroy
                         POST   /users(.:format)               devise/registrations#create
```

Because of its modularity concept, Devise allows you to [include different modules](https://www.rubydoc.info/github/heartcombo/devise/main/Devise/Models) to your models to add the functionality you need for your app. For example, the `database_authenticable` module allows you to hash the password and validate the authenticity of a user while signing in. The `recoverable` module enables the password reset functionality, and so on.

Also, on the controller level, Devise provides you with some [helpers and filters](https://github.com/heartcombo/devise#controller-filters-and-helpers) like the `authenticate_user!` helper function, which denies controller access to unauthenticated users.

So yeah, Devise sets up many things for you, but once you have added it to your project, you need to maintain your user's table and all the information related to the user's identity.

### OmniAuth

[OmniAuth](https://github.com/omniauth/omniauth) is a library that allows you to implement **multi-provider authentication for web applications**. For example, if you wanted to authenticate your users using their Google or Facebook accounts, you could use the OmniAuth gem to delegate the authentication to those providers.

OmniAuth introduces the concept of strategies. A strategy is a provider who will perform the authentication. In the example above, it'll be the Google and Facebook strategies.

**Auth0 has implemented an OmniAuth strategy called [omniauth-auth0](https://github.com/auth0/omniauth-auth0)**. You might know it as the [Ruby on Rails SDK](https://auth0.com/docs/quickstart/webapp/rails), which you can use to implement authentication in a Rails web application.

Let's use the Auth0 strategy to understand how OmniAuth works. OmniAuth assumes that there are two parts to the process of authentication. **The request phase and the callback phase** which is illustrated in the following diagram:

![omniauth and omniauth-auth flow](https://images.ctfassets.net/23aumh6u8s0i/6pDavCvv3R9bJLxGphYCPV/8d28805e843f3afe06663a2239b671b7/Web_App_vs_API_Auth_POV.jpg)

The request phase is typically a redirect to the provider's website, in this case, Auth0. Then Auth0 will authenticate the user and (optionally) ask permission to share information about them with the application. Finally, Auth0 redirects to your application, sending along data about the user, such as an [ID Token](https://auth0.com/docs/secure/tokens/id-tokens) and an [Access Token](https://auth0.com/docs/secure/tokens/access-tokens), as well as other information the user permitted to share. You can then catch that information by implementing a `callback` action in your authentication controller. This action will be automatically called once the user authentication process has finished. 

Your authentication controller would then look similar to this: 

```ruby
# ./app/controllers/auth0_controller.rb
class Auth0Controller < ApplicationController
  def callback
    # OmniAuth stores the information returned from Auth0 and the IdP in request.env['omniauth.auth'].
    # In this code, you will pull the raw_info supplied from the id_token and assign it to the session.
    # Refer to https://github.com/auth0/omniauth-auth0#authentication-hash for complete information on 'omniauth.auth' contents.
    auth_info = request.env['omniauth.auth']
    session[:credentials] = {}
    session[:credentials][:id_token] = auth_info['credentials']['id_token']
    session[:credentials][:access_token] = auth_info['credentials']['token']

    # Redirect to the URL you want after successful auth
    redirect_to '/dashboard'
  end

  def failure
    # Handles failed authentication -- Show a failure page (you can also handle with a redirect)
    @error_msg = request.params['message']
  end

  def logout
    # you will finish this in a later step
  end
end
```

To learn more about how to integrate the ominiauth-auth0 gem into your app, you can [install the SDK](https://auth0.com/docs/quickstart/webapp/rails/01-login#install-the-auth0-sdk) and follow the [Ruby on Rails Quickstart](https://auth0.com/docs/quickstart/webapp/rails). 

This approach allows you to **delegate all the authentication functionality to a third party like Auth0**, meaning that you don't have to store anything related to the user's identity other than the Access Token to make authorized requests in the future.

<include src="SignupCTA" text="Try out Auth0 authentication for free." linkText="Get started →" />

#### When to use Devise or OmniAuth?

As usual in software engineering, it depends on your use case. You should use Devise if you want to be the maintainer of the infrastructure that manages your users' identity. If you want to allow your users to use your application by authenticating with other providers, you should use OmniAuth.

There is an option to [combine Devise with OmniAuth](https://github.com/heartcombo/devise#omniauth) thanks to Devise's implementation, which allows you to get the best of both worlds.

## Authorization Gems 

### Pundit

[Pundit](https://github.com/varvet/pundit) is an **authorization gem** that allows you to restrict certain parts of your Rails application to authorized users. Pundit provides a set of helpers which guide you in leveraging regular Ruby classes and object-oriented design patterns to build a simple, robust, and scalable authorization system.

Pundit is focused on the notion of policy classes, and a policy is nothing more than a list of methods where you specify who can do what. For example, imagine you have the typical `Post` model; then you'd have a `PostPolicy` such as:

```ruby
class PostPolicy
    attr_reader :user, :post

    def initialize(user, post)
        @user = user
        @post = post
    end

    def update?
        user.admin? || !post.published?
    end
end
```

And then your controller could look like this:

```ruby
def update
  @post = Post.find(params[:id])
  authorize @post
  if @post.update(post_params)
    redirect_to @post
  else
    render :edit
  end
end
```

The `authorize!` method automatically infers that `Post` will have a matching `PostPolicy` class and instantiates this class, handing in the current user and the given record. It then infers from the action name that it should call `update?` on this instance of the policy. You'd usually put all the policy classes under `app/policies`, and each domain object should have its respective policy class. 

### CanCanCan

[CanCanCan](https://github.com/CanCanCommunity/cancancan) is the successor of CanCan, the official authorization library for Rails back in the day. CanCanCan is an authorization library for Ruby and Ruby on Rails which restricts what resources a given user is allowed to access.

The gem consists of two main parts:

- **Authorizations library:** allows you to define the rules to access different objects and provides helpers to check for those permissions.
- **Rails helpers:** simplify the code in Rails controllers by automatically loading and checking the permissions of models and reducing duplicated code.

Similarly to Pundit, CanCanCan provides a new concept called ability. An ability is a class where you manage all authorizations. If you think about the `Post` example from above, in CanCanCan, you will define an ability such as:

```ruby
# abilities.rb 

class Ability 
include CanCan::Ability 
    
    def initialize(user) 
        can :read, Post, public: true 
        
        return unless user.present? 
        can :read, Post, user: user 

        return unless user.admin?
        can :read, Post
    end
end
```

In this case, three rules are defined when it comes to reading a `Post`. Each ability can have the form `can actions, subjects, conditions`. You could then create your `PostsController` such as:

```ruby
class PostsController < ApplicationController
    def show
        @post = Post.find(params[:id])
        authorize! :read, @post
    end
end
```

In this example, if a post is public, when calling [the `authorize!` helper](https://github.com/CanCanCommunity/cancancan/blob/develop/docs/controller_helpers.md#authorize) in your controller, even non-authenticated users will be authorized to read it. In the second case defined in the ability file, you need a user to be authenticated, and in the last, the user must have the `admin` role. 

CanCanCan also offers the possibility to define abilities with "cannot" instead of "can", in case that makes more sense for the readability of your permission.

### When to use Pundit or CanCanCan?

As you saw, both gems introduce similar concepts like policies and abilities. CanCanCan is easy to use and very straightforward, especially if you have a small number of domain objects; because you have a single ability class, it can get messy.

Pundit allows you to have one class per domain object, making it cleaner, but it's a bit more complicated when you start using it. Using Pundit might be a good option for its modularity if you have many domain objects.

## A Special Guest: The JWT Gem

As you may know, JWT stands for [JSON Web Token](https://auth0.com/docs/secure/tokens/json-web-tokens), a standard that defines a compact and self-contained way for securely transmitting information between parties as a JSON object.

JWT tokens are usually [used for authentication and authorization.](https://auth0.com/docs/secure/tokens/json-web-tokens#use) For example, if you have a Web API that needs to have secured endpoints, a good option would be to use token-based authorization with JWTs.

[The JWT gem](https://github.com/jwt/ruby-jwt) is a ruby gem to handle JSON Web Tokens, and it is pretty straightforward; its primary function is to encode and decode JWTs.

For example, let's assume you want to encode a payload using a [RSA signature](https://auth0.com/docs/get-started/applications/signing-algorithms).

```ruby
rsa_private = OpenSSL::PKey::RSA.generate 2048
rsa_public = rsa_private.public_key

payload = { some: :cool_payload }

token = JWT.encode payload, rsa_private, 'RS256'
```

The value of `token` will be: 

```bash
"eyJhbGciOiJSUzI1NiJ9.eyJzb21lIjoiY29vbF9wYXlsb2FkIn0.Ku0-CNRgp_wViDIhj0SJgsrsyPNKc3rqCW-2P7KMVgvfInlaqoMKPTGfOUfXLeGX33H2ZX0_9PBNfi0Gh6sg5XbJ3wOPSZ4f4kDMCF32hlmPpvmfPkOgQuOnjTtPayPlLs98mZdH1QzQ_j-Ru1BKnVhlOXLcwaYFUiHpMOs6TjAHW5Fcp3yXBezYvrFi2Q4eSTSd3SgamFTmD4UUL4sQvQEFn2eu58SPojoKkZd6qqY6n-aaqncNcOpYNzInULIrSoza0B1FknSfu09dWLin7I0zCG18iUw8qemVKKHjaIpjx5tFAbOu_vjQUrKwiwPMAUL9fjzdjUW7ZbKgeXyQag"
```

You can then use the `JWT.decode` function to decode it, and it will return:

```bash
3.1.2 :007 > decoded_token = JWT.decode token, rsa_public, true, { algorithm: 'RS256' }
 => [{"some"=>"cool_payload"}, {"alg"=>"RS256"}] 
```

An excellent way to also decode tokens and inspect them is going to [jwt.io](https://jwt.io/) and pasting the token you just got from this blog post to see it decoded:

![JWT.io](https://images.ctfassets.net/23aumh6u8s0i/2QecdE0lXJFWBgpWbNaXJ9/a901c937146fb98b622c9fcac4cdade6/jwtioscreenshot__1_.png)

## Summary

In this post, you learned about five different Ruby gems used for authentication and authorization and when to use them.

For authentication, you can handle the process using a database with Devise, delegate the authentication to a third-party using OmniAuth, or merge them and get the best of both worlds:

#### Devise 

- As a Rails-centric gem, it requires Rails knowledge before getting started.
- Uses Rails engines to take care of a lot of the authentication.
- Requires you to maintain the infrastructure that manages your users' identity. 

#### OmniAuth

- Offers multi-provider authentication 
- Works with multiple Ruby frameworks 
- It's supported by [multiple providers](https://github.com/omniauth/omniauth/wiki/List-of-Strategies) like Auth0

For authorization, Pundit and CanCanCan offer similar concepts but depending on the number of domain objects you have, and you might want to use one over the other:

#### Pundit

- Offers better modularization when having many domain objects. 
- Introduces the concept of policies to handle what a user can do.
- It can be a little complicated to get started.

#### CanCanCan 

- Introduces the concept of abilities to handle what a user can do.
- Recommended if you have a small number of domain objects. 
- Is easy to set up and use.
  
Finally, you learned about the JWT gem, which you can use to encode and decode JWT tokens.

**What other gems do you use for authentication and authorization?**

Let me know in the comments!

Thanks for reading!

Five Ruby Gems for Authentication and Authorization

john-brennan

John is an R&D Content Engineer at Auth0. He has nearly a decade’s experience in full-stack software development in a variety of environments, languages, and frameworks. He relishes the challenge of learning hard-to-grasp technical concepts and helping others understand them in a clear, concise manner. His current technical interests are in API design and scalability, Ruby on Rails, accessibility, single-page app architecture, and the ever-changing JavaScript ecosystem. When he's not working, John is usually cooking, doing creative writing, running, or wrangling a toddler.

R&D Content Engineer

John Brennan

Learn how to easily integrate Auth0 with Rails 6 to build secure APIs.

**TL;DR:** In this tutorial, you'll learn how to use Rails 6 and Auth0 to build an API with both authorized and open endpoints.

The ecosystem for building backend services feels more crowded than ever before. With a multitude of choices for building APIs and backend services &mdash; from Node.js frameworks and web applications to lightweight serverless functions &mdash; it's sometimes easy to overlook longstanding, tried-and-true frameworks like Ruby on Rails, which (as of 2020) is now 15 years old!

Rails sometimes gets a bad rap for not being the newest or shiniest framework out there. But Rails continues to provide sensible defaults, the ability to quickly generate scaffolding for your web apps and APIs, and constant iterative progress of new features. With Rails 6, that includes easy management of multi-environment credentials, the new Zeitwork autoloader, and [many other features beyond the scope of this tutorial](https://edgeguides.rubyonrails.org/6_0_release_notes.html).

In this tutorial, you'll see how straightforward it is to spin up a new Rails API, add JSON Web Token (JWT) support to make authorized requests and secure your endpoints, and leverage Auth0 as your authentication system to verify users and access tokens. The API you'll build is a simple one: you'll create an endpoint for reading, creating, and deleting short messages called Chirps &mdash; think of it as your own private Twitter API.

<include src="TweetQuote" quoteText="With Rails 6 and Auth0, it's straightforward to spin up an API and secure your endpoints."/>

You can find all code from this tutorial in [this GitHub repository](https://github.com/auth0-blog/auth0_rails_api).

Read on to get started!

## Prerequisites

- **Rails** and prerequisites. You'll need to install Rails itself before you can use the Rails CLI. If you already have Ruby installed, you can install Rails like so: `gem install rails`. You'll also need Rails' prerequisites: Ruby and SQLite3. You can find full instructions on installing Rails [on the Ruby on Rails guide site](https://guides.rubyonrails.org/getting_started.html#creating-a-new-rails-project-installing-rails)
- An **Auth0 account**. If you don't have one, you can <a href="https://auth0.com/signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">sign up for a free Auth0 account here</a>.

<include src="SignupCTA" text="Try out the most powerful authentication platform for free." linkText="Get started →" />

## Create a New Auth0 API

Before you jump into code, you'll need to create a new Auth0 API. Head to the [API section of your Auth0 dashboard](https://manage.auth0.com/#/apis) and click the orange "Create API" button. Fill out the form with the following values:

* **Name**: Rails Secure API
* **Identifier**: https://rails-secure-api
* **Signing Algorithm**: RS256 (this should be the default selection)

![Creating a new Auth0 API](https://images.ctfassets.net/23aumh6u8s0i/2BP2PXs9B725VW9LJ9p5Vb/b8e3e0464678b0c07d960a7c65895dd4/create-new-auth0-api)

Copy the `identifier` value (`https://rails-secure-api`) &mdash; you'll need it when setting up your Rails app. You'll also need to grab your **Auth0 Domain**. Unless you're using a custom domain, this value will be `[TENANT_NAME].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](https://images.ctfassets.net/23aumh6u8s0i/4rf8o8qBpVmWhMORzdgjJJ/13a6ebdb502ddade0f3817beb7b7f589/find-auth0-domain.png)

Once you've finished creating your API, you can head to the command line and start building your Rails application!

## Scaffolding

The most straightforward way to generate a new Rails app is by using the CLI. Run the following command in your terminal:

```bash
$ rails new auth0_rails_api --api
```

Once the Rails CLI finishes, you'll have a fully operational Rails application ready to go. To ensure this, run the following in your command line:

```bash
$ cd auth0_rails_api
$ bundle exec rails s
```

Navigate to [http://localhost:3000](http://localhost:3000) in your browser; you should see a standard "greeting" screen indicating that the Rails app is successfully running:

![Rails greeting screen](https://images.ctfassets.net/23aumh6u8s0i/1c6JsBwMyoMGbuxvPDv73T/b29bc5822a3e0aa1104ac9643f451034/new-rails-app)

Now that you're up and running, it's time to start building your API. Stop the running Rails process (`ctrl + c`) and read on!

## Create Authorization Handlers

In this section, you'll build a class for handling JSON Web Token (JWT) verification, plus a service that uses the JWT class to perform authorization when new requests are sent to your API.

First, you'll need to add the `jwt` gem to your application. Open `Gemfile` in your project's root directory and add the following line to the file:

```
gem 'jwt'
```

Run `bundle install` from the command line to install the gem.

Next, you need to add the API identifier and domain values from your Auth0 configuration into your Rails environment.

In your command line, run the following:

```bash
$ bundle exec rails credentials:edit --environment development
```

> Tip: If you don't have a default text editor set up in your command line, you may need to pass an `EDITOR` argument with the command, e.g., `EDITOR="vim" bundle exec rails credentials:edit --environment development`

If you've used Rails 5, you're probably familiar with [the introduction of encrypted credentials in Rails 5.2](https://blog.engineyard.com/rails-encrypted-credentials-on-rails-5.2). The reason you're passing `--environment development` into the argument is a Rails 6 development &mdash; [credentials now support multiple environments!](https://blog.saeloun.com/2019/10/10/rails-6-adds-support-for-multi-environment-credentials.html)

When the credentials file opens, delete any existing contents and add the code snippet below. Be sure to replace `{AUTH0_DOMAIN}` with the **Auth0 Domain** value you copied down in the "Create a New Auth0 API" section. If you used a custom `identifier` value in that section, you'll also need to replace the `api_identifier` value.

```yaml
auth0:
  api_identifier: https://rails-secure-api
  domain: {AUTH0_DOMAIN}
```

After you've saved the credentials file, open your project directory in your code editor of choice. Create a directory under `app` called `lib` and create a new file called `json_web_token.rb`.

> Tip: The reason you're creating the new class in `app/lib` rather than `lib` is that subdirectories under `app` are autoloaded by default. If you're not familiar with Rails 6 autoloading with the Zeitwork engine, the [Rails guide to autoloading](https://guides.rubyonrails.org/autoloading_and_reloading_constants.html) or [this article on understanding Zeitwork in Rails 6](https://medium.com/cedarcode/understanding-zeitwerk-in-rails-6-f168a9f09a1f) can provide more information.

Add the following to `json_web_token.rb`:

```ruby
# app/lib/json_web_token.rb
require 'net/http'
require 'uri'

class JsonWebToken
  def self.verify(token)
    JWT.decode(token, nil,
               true, # Verify the signature of this token
               algorithm: 'RS256',
               iss: "https://#{Rails.application.credentials.auth0[:domain]}/",
               verify_iss: true,
               aud: Rails.application.credentials.auth0[:api_identifier],
               verify_aud: true) do |header|
      jwks_hash[header['kid']]
    end
  end

  def self.jwks_hash
    jwks_raw = Net::HTTP.get URI("https://#{Rails.application.credentials.auth0[:domain]}/.well-known/jwks.json")
    jwks_keys = Array(JSON.parse(jwks_raw)['keys'])
    Hash[
      jwks_keys
      .map do |k|
        [
          k['kid'],
          OpenSSL::X509::Certificate.new(
            Base64.decode64(k['x5c'].first)
          ).public_key
        ]
      end
    ]
  end
end
```

This class is taken pretty much verbatim from the [Auth0 Rails API QuickStart](https://auth0.com/docs/quickstart/backend/rails). It performs the actual verification of the JWT-formatted access token that API requests will provide.

Next, create a subdirectory under `app` called `services`. Create a new file called `authorization_service.rb` and add the following to it:

```ruby
class AuthorizationService

  def initialize(headers = {})
    @headers = headers
  end

  def authenticate_request!
    verify_token
  end

  private

  def http_token
    if @headers['Authorization'].present?
      @headers['Authorization'].split(' ').last
    end
  end

  def verify_token
    JsonWebToken.verify(http_token)
  end

end
```

By extracting the authorization logic to a service, you're separating the concerns of *verifying the authenticity* of a JWT versus *authorizing an HTTP request*. The `AuthorizationService` grabs the access token in the `Authorization` HTTP Header and passes it to the `JsonWebToken` for verification.

With this separation of responsibility, you can limit any possible future changes to the JWT verification process to the `JsonWebToken` class. With your `AuthorizationService` in place, you can now easily add an authorization check to your controllers &mdash; and you'll do just that in the next section!

## Securing an API Endpoint

### Build a base SecuredController

At this point, you could start creating controllers and adding an authorization check to each controller individually. However, if you're planning to secure your entire API, it's easier to create a base controller from which your secured controllers can inherit the authorization check.

Create a new file called `secured_controller.rb` in `apps/controllers` and add the following to it:

```ruby
class SecuredController < ApplicationController
  before_action :authorize_request

  private

  def authorize_request
    AuthorizationService.new(request.headers).authenticate_request!
  rescue JWT::VerificationError, JWT::DecodeError
    render json: { errors: ['Not Authenticated'] }, status: :unauthorized
  end
end
```

The `SecuredController` inherits from `ApplicationController` and adds a `before_action` call, ensuring that every request will pass through the `AuthorizationService` before running any additional handlers. `SecuredController` also handles returning a `401 Unauthorized` response if the request doesn't pass muster.

One more thing: you'll want to disable [Parameter Wrapping](https://api.rubyonrails.org/v6.0.3.1/classes/ActionController/ParamsWrapper.html) in our API, for simplicity's sake. Open `config/initializers/wrap_parameters.rb` and change the uncommented code to read as follows:

```ruby
# ...
ActiveSupport.on_load(:action_controller) do
  wrap_parameters format: []
end
```

And with that, your scaffolding is complete, and you're ready to create a real live secured API endpoint!

### Build an API endpoint

The Rails CLI can be used to create the various moving pieces you need for an API endpoint. Head to your command line again and run the following:

```bash
$ bundle exec rails generate resource chirp body:text published:boolean
$ bundle exec rails db:migrate
```

The `resource` generator is a quick way to create a model, controller, and route (plus unit tests) for your new `Chirp` data type. Running `rails db:migrate` afterward creates the necessary tables in your database.

With your scaffolding complete, it's time to write the code to handle your endpoint!

First, open up `app/models/chirp.rb` and add the following to the model class:

```ruby
class Chirp < ApplicationRecord
  # 👇 Add this line 👇
  validates_presence_of :body, :published
end
```

This line will validate the `body` and `published` fields when a new Chirp is created and automatically return a `422` response code when a `POST` request without those fields is received.

Next, open `app/controllers/chirps_controller.rb` and replace the contents with the following:

```ruby
class ChirpsController < SecuredController
  def index
    chirps = Chirp.all
    render json: chirps
  end

  def show
    chirp = Chirp.find(params[:id])
    render json: chirp
  rescue ActiveRecord::RecordNotFound
    head :not_found
  end

  def create
    chirp = Chirp.create!(chirp_params)
    render json: chirp, status: :created
  end

  def destroy
    chirp = Chirp.find(params[:id])
    chirp.delete
    head :no_content
  end

  private

  def chirp_params
    params.permit(:body, :published)
  end
end
```

If you've worked with Rails before, this should look pretty straightforward. The controller supports `GET` requests (both of specific Chirps and all Chirps), `POST`s to create new Chirps, and `DELETE`s to destroy specific Chirps.

It's important to note that the code sample changes the controller's inheritance chain. The generated controller inherits from `ApplicationController`, whereas the above code inherits from `SecuredController`, so all requests must include an access token.

### Allowing unauthenticated requests

Your API endpoint should now be working, but there's one issue: much like Twitter, you might want your Chirps to be publicly viewable! For that to work, unauthenticated `GET` requests need to be allowed, but `POST` and `DELETE` requests should still require an access token.

Luckily, allowing this is straightforward. Add the following line to the top of your `ChirpsController` class:

```ruby
class ChirpsController < SecuredController
  skip_before_action :authorize_request, only: [:index, :show]
  # 👆 New Code 👆

  # 👇 Existing Code 👇
```

With `skip_before_action`, individual controllers like `ChirpsController` can easily override the default `SecuredController` behavior as needed.

And with that, your API is ready to go!

### Test it out

To test your API, head back to the [API page of your Auth0 Dashboard](https://manage.auth0.com/#/apis) and click on "Rails Secure API" to view the API details. Click the "Test" tab and scroll down to the "Asking Auth0 for tokens from my application" section. Under the "Response" heading, you can copy a test access token to use in requests to your API.

![find access token on Auth0 API Details page](https://images.ctfassets.net/23aumh6u8s0i/346OJCiphrtCFAMqCDNhAT/610c50a0f000b57732652d152604c9f7/find-access-token)

Access token in metaphorical hand, it's time to make a request. In your command line, start the Rails server:

```bash
$ bundle exec rails server
```

(The request examples here use cURL, but Postman or any number of other tools for crafting HTTP requests will work.)

First, request the `chirps` endpoint without your access token to ensure unauthenticated GET requests work:

```bash
$ curl http://localhost:3000/chirps
```

You should see the following response:

```
[]
```

Your request is working, but since no Chirps exist in the database, an empty array comes back.

Next, make an unauthenticated `POST` request to ensure your `SecuredController` implementation is correct:

```bash
$ curl -H "Content-Type: application/json" -d '{"body":"this is my first chirp!", "published":true}' -X POST http://localhost:3000/chirps
```

You should see the following response:

```
{"errors":["Not Authenticated"]}
```

Success! Without an access token, you can't create a chirp.

Let's successfully create a Chirp; To do so, you'll need to add the `Authorization` header to your request. Replace `[ACCESS_TOKEN]` with the token from your Auth0 dashboard and run the following command:

```bash
$ curl -H "Content-Type: application/json" -H "Authorization: bearer [ACCESS_TOKEN]" -d '{"body":"this is my first chirp!", "published":true}' -X POST http://localhost:3000/chirps
```

And the response:

```
{"id":1,"body":"this is my first chirp!","published":true,"created_at":"2020-06-08T21:13:03.949Z","updated_at":"2020-06-08T21:13:03.949Z"}
```

(Timestamps may vary, obviously!)

You've successfully made a secure request to your API and created your first Chirp!

You can now request that record without needing an access token:

```bash
$ curl http://localhost:3000/chirps/1
```

To delete the record, you'll need to provide the access token once again:

```bash
$ curl -i -H "Authorization: bearer [ACCESS_TOKEN]" -X DELETE http://localhost:3000/chirps/1
```

The `-i` argument is provided to view the full HTTP response, including headers. You should see a response similar to the following:

```
HTTP/1.1 204 No Content
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
X-Download-Options: noopen
X-Permitted-Cross-Domain-Policies: none
Referrer-Policy: strict-origin-when-cross-origin
Cache-Control: no-cache
X-Request-Id: c44a6a80-74d5-40ab-a03a-883714f41d32
X-Runtime: 0.125480
```

A `204` response is what you specified in the controller on a successful delete, which means it worked. Your API is now fully operational, and you're on your way to creating your own miniature Twitter!

## Conclusion

Rails is an excellent choice for spinning up APIs and using the many tools it provides to build and secure your endpoints. While well-known gems like [devise](https://github.com/heartcombo/devise) exist to build your own token authentication solution, it adds complexity and overhead to building and maintaining your API. Using Auth0 for authentication and credential handling, social login, and features like [role-based access control](https://auth0.com/docs/authorization/concepts/rbac) and [custom user metadata](https://auth0.com/docs/users/concepts/overview-user-metadata), you can keep the complexity of user management separated from your authorization and business logic in your codebase.

Some next steps to take could be to continue building the functionality of your API or start exploring Auth0's [QuickStarts for JavaScript single-page apps](https://auth0.com/docs/quickstart/spa) to create a front-end for your API. Front-end apps can perform the initial authentication with Auth0, providing you with the access token you need to communicate with your API.

The repository for the complete application described in this tutorial can be found [on GitHub](https://github.com/auth0-blog/auth0_rails_api).

Happy building!

Building Secure APIs with Rails 6 and Auth0

Learn how to secure an API written using Ruby On Rails with Auth0 authorization services.

If you want to expose an API publicly on the Internet, authorization will be a requirement for you sooner or later. You want to verify that the client consuming the API has the appropriate permissions.

This guide is exactly about that. We'll be securing an API written using [Ruby On Rails](https://rubyonrails.org/), with [Auth0](https://auth0.com/) as the authorization server.

There's a repository with the code so that you can follow along in [Github](https://github.com/auth0-blog/rails-api-auth0).

## Securing an API

I didn't explain what I mean by securing an API yet. Essentially, we're ensuring that protected routes are accessible only for the users with enough rights.

When it comes to security, it's generally considered a bad idea to roll your own bespoke implementation. Instead, I'm using [OAuth](https://auth0.com/docs/protocols/protocol-oauth2), a battle-tested and widely used authorization framework for web applications.

In this context, Auth0 fulfills the role of the _authorization server_ and abstracts a significant part of the work away from us. That way, we can focus on delivering value to our users.

Without getting into too many details on how OAuth works, we assume that calls to our API will include a bearer token using the industry-standard [JWT](https://jwt.io/) format. The token contains a series of claims regarding its issuer, how long it is valid, and what rights it grants. Let's have a look at a sample token:

```json
{
  "iss": "https://yourTenant.eu.auth0.com/",
  "sub": "zHwnsh0j2sTj4u3ss6YedSFrzyb2",
  "aud": "https://targetAudience.com",
  "iat": 1621369130,
  "exp": 1791455530,
  "azp": "ThEkgdG1NndLlWoNMcEdEr2KJIs9vKad",
  "scope": "openid profile read:admin-messages",
  "permissions": ["read:admin-messages"]
}
```

We're going to implement verification for that token and reject requests that don't have the required permissions.

## Getting Started

We're getting started with our base application, bootstrapped with Rails 6. This [branch](https://github.com/auth0-blog/rails-api-auth0/tree/starter) is a good starting point. You can download it by running the following command in a terminal window:

```shell
git clone -b starter --single-branch https://github.com/auth0-blog/rails-api-auth0.git
```

The API has three endpoints with different levels of protection:

- `/api/messages/public`: Public route.
- `/api/messages/protected`: Requires a valid access token.
- `/api/messages/admin`: Requires a valid access token. Since Auth0 uses JWT as its access token format, we can inspect it and make sure it has a `permissions` claim that contains the scope `read:admin-messages`.

### Running the Application

To run the application, we first need the correct ruby version. The easiest way to do so is to use a version manager like [rbenv](https://github.com/rbenv/rbenv). Once you install it, run this command inside the repository to install the right version of ruby:

```shell
rbenv install
```

Install the dependencies for the application:

```shell
bundle install
```

And finally, run the application:

```shell
bin/rails s
```

You can verify that the application is working correctly with `curl`:

```shell
curl localhost:6060/api/messages/public
```

The command will return a 200 code, plus the message:

```json
{"message": "The API doesn't require an access token to share this message."}
```

### Creating an API on Auth0

To secure the API with Auth0, you need an Auth0 account. If you haven't one, you can <a href="https://auth0.com/signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">sign up for free</a> right now. In the *APIs* section of the [Auth0 dashboard](https://manage.auth0.com/), click *Create API*. Provide a name and an identifier for your API. You will use the identifier as an `audience` later, when you are configuring the access token verification. Leave the *Signing Algorithm* as RS256.

![Create API](https://images.ctfassets.net/23aumh6u8s0i/5y9rQHvjBzjxQo5aDIrsKE/842c2fadf99e521fc20a8326dfa8ee2e/create-auth0-api.png)

Once you create the API, go to the _Permissions_ tab in the API details and add a permission called `read:admin-messages`.

![Create permission](https://images.ctfassets.net/23aumh6u8s0i/jT9dzB4AcCM0BAoYgCizu/2abc44d5604d03267b957281e93749a8/configure-permissions.png)

> **Note**: While you are in the Auth0 Dashboard, take note of your Auth0 domain. You will need it soon. This is a string in the form `YOUR-TENANT-NAME.auth0.com` where `YOUR-TENANT-NAME` is the name you provided when you created your account with Auth0. For more information, [check the documentation](https://auth0.com/docs/getting-started/the-basics#domains).

## Preparing the Application for Validation

Alright, our application is ready to go and in dire need of some _security_. Before that, we need to add some configurations.

You dutifully stored the `domain` and the `audience` after creating the API, right? Let's use them. In the _Rails_ world, the convention is to add this in the `config` folder, using [YAML](https://yaml.org/). The file is called `config/auth0.yml`.

We don't want to store credentials in our code, so we'll export the values as environment variables, named `AUTH0_DOMAIN` and `AUTH0_AUDIENCE`. The configuration uses those values and keeps them safely away from source control!

```yaml
development:
  issuerUri: <%= ENV["AUTH0_DOMAIN"] %>
  audience: <%= ENV["AUTH0_AUDIENCE"] %>
```

Now, set `AUTH0_DOMAIN` and `AUTH0_AUDIENCE` environment variables to the `domain` and `audience` values for your API.

With this, the application is ready to connect with Auth0. Let's move on to the implementation.

## Validating the Access Token

Before we get started, let's talk for a second about authentication frameworks for rails. There are a bunch of alternatives in the ecosystem, such as [CanCanCan](https://github.com/CanCanCommunity/cancancan), or [devise](https://github.com/heartcombo/devise).

However, our case is an awkward fit for those. We don't want to take over user management. We only want to validate tokens issued by the authorization server. In this case, using a framework won't bring us as much benefit as something like, say, [Spring Security](https://spring.io/projects/spring-security). That's why we only rely on an extra gem, [jwt](https://github.com/jwt/ruby-jwt).

The code implementing the authorization check lives in the [add-authorization](https://github.com/auth0-blog/rails-api-auth0/tree/add-authorization) branch. Let's see how it works!

### Utilizing the JWT Library

The `jwt` library brings a lot of functionality to make our API able to validate and manage tokens in JWT formats like the ones issued by Auth0. We need to do three things:

- We need to fetch the [JWKS](https://auth0.com/docs/tokens/json-web-tokens/json-web-key-sets) configuration from _Auth0_ so that we know what is the public key to verify the access token signature
- With the public key, the issuer, and the audience, we want to verify the token
- After verifying the token, we're decoding it to access the `permissions` claim (or any other information contained in the token, really)

### Decoding the Token

Let's get down to business. We're implementing the verification/decoding logic in the `lib` folder, in a file called `json_web_token.rb`. We're starting by fetching the _JWKS_ data:

```ruby
# lib/json_web_token.rb
require 'jwt'
require 'net/http'

class JsonWebToken
  class << self
    def algorithm
      'RS256'
    end

    def key(header)
      jwks_hash[header['kid']]
    end

    def jwks_hash
      jwks_raw = Net::HTTP.get URI("#{issuer}.well-known/jwks.json")
      jwks_keys = Array(JSON.parse(jwks_raw)['keys'])
      jwks_keys.map do |k|
        [
          k['kid'],
          OpenSSL::X509::Certificate.new(Base64.decode64(k['x5c'].first)).public_key
        ]
      end.to_h
    end

    def issuer
      "https://#{Rails.application.config.x.auth0.issuerUri}/"
    end
  end
end
```

As you can see, through the `issuerUri` we know where to look for the data. Then, we parse the key so that we can consume it in the library.

The next step is to add an extra method to the class, `verify`, that verifies and decodes the token at the same time:

```ruby
# lib/json_web_token.rb
class JsonWebToken
  class << self
    def verify(token)
      JWT.decode(token, nil,
                 true, # Verify the signature of this token
                 algorithm: algorithm,
                 iss: Rails.application.config.x.auth0.issuerUri,
                 verify_iss: true,
                 aud: Rails.application.config.x.auth0.audience,
                 verify_aud: true) do |header|
        key(header)
      end
    end
    
    # ... existing code ...
    
  end
end
```

This is all the code that we need for the actual verification. Neat, isn't it? But our controllers are still insecure. Not for long, though.

## Protecting the Endpoints

To make it as convenient as possible, we're creating a hook that we're going to run before any route that needs authentication. To make it available for every controller, it lives in the `app/controllers/application_controller.rb`:

```ruby
# app/controllers/application_controller.rb
require 'json_web_token'

class ApplicationController < ActionController::API
  def authorize!
    valid, result = verify(raw_token(request.headers))

    head :unauthorized unless valid

    @token ||= result
  end

  private

  def verify(token)
    payload, = JsonWebToken.verify(token)
    [true, payload]
  rescue JWT::DecodeError => e
    [false, e]
  end

  def raw_token(headers)
    return headers['Authorization'].split.last if headers['Authorization'].present?

    nil
  end
end
```

We take the token from the standard _Authorization_ header. Then, we verify it with the code from the previous section. There are two possible paths after running `authorize!`:

- If the token isn't there, or it's invalid for any reason, the processing stops right there, and the call returns a 401
- If the token is valid, we continue the execution and store the token in `@token` so that it's available

We're protecting both the `protected` and the `admin` routes with this hook, thanks to [before_action](https://api.rubyonrails.org/v6.1.4/classes/AbstractController/Callbacks/ClassMethods.html#method-i-before_action):

```ruby
# app/controllers/api/messages_controller.rb
module Api
  class MessagesController < ApplicationController
    before_action :authorize!, except: %i[public]
end
```

### Custom Error Messages

Don't you feel better knowing that the application is not exposing private stuff anymore? I definitely do. But we got to help our users. A blank 401 message might not give them enough information to debug the issue. Let's extend the hook to return something more explicit:

```ruby
# app/controllers/application_controller.rb
class ApplicationController < ActionController::API
   def authorize!
     valid, result = verify(raw_token(request.headers))

     # 👇 old code
     # head :unauthorized unless valid
     # 👇 new code
     render json: { message: result }.to_json, status: :unauthorized unless valid

     @token ||= result
   end
```

Now we get a message that's more helpful than an HTTP code without a body.

## Testing the Protected Endpoints

Let's test the protected endpoint:

```shell
curl localhost:6060/api/messages/protected
```

The command will return a 401, because we're not authorized. We need to get a valid token from Auth0.

The simplest way is to access the [API section of your Auth0 Dashboard](https://manage.auth0.com/#/apis) again, select the API that you created before and click the *Test* tab. In this section, you can get a temporary token to test your Web API by clicking the *Copy Token* icon as shown in the following picture:

![Test Token](https://images.ctfassets.net/23aumh6u8s0i/6zmU9XWwgZLWIAFF0qu6IP/50e2aa27469142c138b814731aa0233d/copy-access-token.png)

Let's attach the token to the request:

```shell
export TOKEN=the-test-token
curl localhost:6060/api/messages/protected -H "Authorization: Bearer $TOKEN"
```

The request works now! 

```json
{"message": "The API successfully validated your access token."}
```

## Checking for permissions

There's one requirement pending. As you might recall, for `/api/messages/admin` a valid token isn't enough. Rather, we expect the correct permission in the `permissions` claim. This extra check allows us to define more granular access criteria for our endpoints. This functionality is implemented in the [add-rbac](https://github.com/auth0-blog/rails-api-auth0/tree/add-rbac) branch.

We're adding a new method in the `application_controller`, `check_permissions`. It takes the decoded token and looks for a given permission:

```ruby
# app/controllers/application_controller.rb
require 'json_web_token'

class ApplicationController < ActionController::API
  # ... existing code ...
  
  def can_read_admin_messages!
    check_permissions(@token, 'read:admin-messages')
  end
  
  def check_permissions(token, permission)
    permissions = token['permissions'] || []
    permissions = permissions.split if permissions.is_a? String

    unless permissions.include?(permission)
      render json: { message: 'Access is denied' }.to_json,
             status: :unauthorized
    end
  end
  
  # ... existing code ...
end
```

We use a `before_action` again to protect the `admin` endpoint:

```ruby
# app/controllers/api/messages_controller.rb
module Api
  class MessagesController < ApplicationController
    before_action :can_read_admin_messages!, only: %i[admin]
    
    # ... existing code ...
end
```

With this, each route in our sample application is safe the way we wanted.

### Testing Permissions

If you try to call the `/api/messages/admin` endpoint with the token we generated before, it will return a 401. Our token is valid but doesn't have the necessary permissions. Let's create a new one!

Back in your [API configuration page on the Auth0 Dashboard](https://manage.auth0.com/#/apis), select the *Machine to Machine Applications* tab. You'll get a list of applications, some of them with the *(Test Application)* label in the name. These applications are automatically created by Auth0 when you create an API there. They are meant as test clients from your API. One of them should have the *Authorized* switch on. Click the dropdown next to it and check the `read:admin-messages` permission:

![Adding Permissions](https://images.ctfassets.net/23aumh6u8s0i/2Iva8EtxfjdsunLbDTGVyD/71034bf799e82e51c7e5f7152ccd6adf/adding-permissions.png)

Then, click the *Update* button, move again to the *Test* tab, and copy the new token that has been generated for you. Let's try again:

```shell
export TOKEN=the-new-test-token
curl localhost:6060/api/messages/admin -H "Authorization: Bearer $TOKEN"
```

The request works now!

```json
{"message":"The API successfully recognized you as an admin."}
```

## Conclusion

In this guide, we've added authorization to a Rails API by using Auth0 as an authorization server. Thanks to the `jwt` gem, we don't have to invest much effort. We use the library to decode the bearer token that the API receives. After that, it's a matter of checking the relevant routes before each request.


Secure a Rails API with Auth0

685342d5e7f42c3ab8d251d7d4a53308?s=100&d=mm&r=g avatar

685342d5e7f42c3ab8d251d7d4a53308?s=100&d=mm&r=g

Former Auth0 Employee

Robin Percy

Using Ruby on Rails to combine Auth0 Login with Iris Recognition for Two Factor Authentication

"rails"