Authorization in API can be a complex task for developers as it requires a thorough understanding of security and access controls. Authorization is the process of granting or denying access to specific resources, actions, or data based on the user's permissions or roles. In a Ruby on Rails API, authorization can be implemented at the controller level, action level, or attribute level.

No authorization

To understand the complexity of authorization, let's start with a simple Ruby on Rails API controller example that does not have any authorization.

# app/controllers/api/v1/posts_controller.rb

class API::V1::PostsController < ApplicationController
  def create
    @post = Post.new(post_params)
    @post.save!
    render json: serialized(@post)
  end

  def update
    @post = Post.find(params[:id])
    @post.update!(post_params)
    render json: serialized(@post)
  end

  def show
    @post = Post.find(params[:id])
    render json: serialized(@post)
  end

  private

  def serialize(post)
    # custom serialization logic
  end
end

In this example, anyone can create, update, or show posts. However, in most applications, only certain users should have access to certain resources or actions.

Action-level authorization

To implement action-level authorization, we can use the before_action method in the controller.

# app/controllers/api/v1/posts_controller.rb

class API::V1::PostsController < ApplicationController
  before_action :authenticate_user!
  before_action :authorize_user!, only: [:create, :update]

  def create
    @post = Post.new(post_params)
    @post.save!
    render json: serialized(@post)
  end

  def update
    @post = Post.find(params[:id])
    @post.update!(post_params)
    render json: serialized(@post)
  end

  def show
    @post = Post.find(params[:id])
    render json: serialized(@post)
  end

  private

  def authorize_user!
    if current_user.role == 'author'
      flash[:error] = "You can't access this page."
      redirect_to root_path
    end
  end

  def serialize(post)
    # custom serialization logic
  end
end

In this example, the authenticate_user! method ensures that only logged-in users can access the API. The authorize_user! method checks if the current user has the author role, and if not, redirects the user to the root path.

While this implementation of action-level authorization works, it is limited in terms of granularity.

Attribute-level authorization

In most applications, authorization needs to be applied not only to actions but also to methods, attributes, and resources. To simplify attribute-level authorization, we can use the resource_policy gem.

The resource_policy is a policy-based authorization gem for Ruby applications. It provides a simple and flexible way to manage authorization at the action, attribute, and resource level.

The policy class looks like this::

# app/policies/post_policy.rb

class PostPolicy
  include ResourcePolicy::Policy

  policy do |c|
    c.action(:create).allowed(if: :editor?)
    c.action(:update).allowed(if: :author?)
    c.action(:show).allowed

    c.attribute(:id).allowed(:read)
    c.attribute(:body).allowed(:read).allowed(:write, if: :author?)
    c.attribute(:author_phone).allowed(:read, if: :admin?)
  end

  delegate :admin?, :editor?, to: :@current_user

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

  def author?
    @post.author == current_user
  end
end

The PostPolicy is a policy class used for authorization of actions and attributes. It includes the ResourcePolicy::Policy module which provides the policy configuration via policy method. This method is used to define the authorization rules for each action and attribute.

The policy method defines the rules for creating, updating, and showing a post, as well as reading and writing the body and author_phone attributes. The authorization rules specify the conditions under which an action or attribute is allowed. For example, creating a post is only allowed if the current user is an editor and updating a post is only allowed if the current user is the author.

Here's the updated code for our API controller with attribute-level authorization using the resource_policy gem:

# app/controllers/api/v1/posts_controller.rb

class API::V1::PostsController < ApplicationController
  before_action :authorize_user!

  def create
    @post = Post.new(post_params)

    when_authorized(@post, :create) do |protected_post|
      @post.save!
      render json: serialized(protected_post)
    end      
  end

  def update
    @post = Post.find(params[:id])
    when_authorized(@post, :update) do |protected_post|
      @post.update!(post_params)
      render json: serialized(protected_post)
    end
  end

  def show
    @post = Post.find(params[:id])
    when_authorized(@post, :show) do |protected_post|
      render json: serialized(protected_post)
    end
  end

  private

  def when_authorized(post, action_name)
    policy = PostPolicy.new(post, current_user)

    if policy.action(action_name).allowed?
      return yield(policy.protected_resource)
    else
      render json: { error: 'not authorized' }, status: 403
    end
  end

  def serialize(post)
    # custom serialization logic
  end
end

Our updated controller does not have before_action :authorize_user! hook anymore, but handles all the authorization logic in when_authorized method.

The when_authorized method is used to wrap the logic in the action methods (create, update, and show). This method takes in two parameters: post and action_name.

The method starts by initializing a PostPolicy object with the post and current_user as parameters. The PostPolicy object at first will determine if the current user is allowed to perform the action specified by action_name on the post. Then it will return protected_resource object.

Protected resource

The protected_resource is a special ResourcePolicy object that returns nil for each unauthorized attribute, and returns the actual value otherwise. This makes it very handy for API calls where you need to return only authorized data.

For demonstration purposes, let's assume we have the two user roles: guest and admin. The following examples show the output of the show action for each of these roles.

Guest role:

{
  "id": 1,
  "body": "This is a sample post body",
  "author_phone": null
}

Admin role:

{
  "id": 1,
  "body": "This is a sample post body",
  "author_phone": "555-555-1234"
}

We have single source of truth. We can always update our PostPolicy configuration when we need to protect more attributes. No more code duplication or accidental data exposure. It wasn't an easy journey, bet we made it.

Final thoughts

Authorization is a complex topic and I tried really hard not to go to deep in to the details. That's why I only touched the very basics of resource_policy gem and how to use it to solve simple-enough authorization problems.

In conclusion, authorization in a Ruby on Rails API is an important aspect of ensuring the security and privacy of data and resources. Without authorization, anyone can access any resource or action in the API, which is unacceptable in most applications. Action-level authorization is a simple solution that can be implemented using the before_action method, but it is limited in its granularity. Attribute-level authorization provides a more flexible and robust solution, and can be achieved using the resource_policy gem. The resource_policy gem allows for the definition of policy classes that specify the authorization rules for actions and attributes, making it easier to manage authorization at different levels of granularity.

In this article, we have covered the basics of authorization in a Ruby on Rails API, and provided examples of how to implement action-level and attribute-level authorization. By understanding the concepts and methods discussed in this article, developers can implement effective authorization in their Ruby on Rails APIs, ensuring the security and privacy of their data and resources.