AuthorizationヘッダーのBearerスキームを使って認証・認可をするRackミドルウェアのGem「rack-bearer_auth」を作りました

RFC 6750で規定されているHTTPのAuthorizationヘッダーのBearerスキームを使ってトークンによる認証・認可をするためのRackミドルウェアのGem「rack-bearer_auth」を作りました。

yujideveloper/rack-bearer_auth

どういうGemか？

APIの認証・認可でトークンを使いたいことってありますよね。
そういうときにOAuth 2.0とかを使ってもいいのですが、ちょっとしたトークンとかで済ませたい時とかありますよね。
そんな時にこのGemの出番です。

Rackミドルウェアとして実装しているので、Ruby on Railsをはじめ、SinatraやHanamiなんかでも使えるんじゃないかと思います。

そもそもRFC 6750はOAuth 2.0の認可機構として規定されているのですが、OAuth 2.0に限らず汎用的なHTTP認可に使用して良いようです。

サンプルコード

Railsで使う場合はconfig/application.rbに以下のような設定を追加します。

module YourApp
  class Application < Rails::Application

    # ...

    config.middleware.use, Rack::BearerAuth::Middleware do
      # 指定したトークンと一致するかで認証・認可
      match path: "/api/foo", via: %i[post patch delete], token: "some_token"


      # ブロック内でトークンの検証をした結果で認証・認可
      match path: "/api/bar", via: :all do |token|
        AccessToken.where(token: token).exists?
      end
    end
  end
end

上記のような設定を入れておくと、リクエストパスとメソッドが一致した場合に、AuthorizationヘッダーのBearerスキームに所定のトークンが指定されているかを検証するようになります。

上記の例では、/api/fooにPOST/PATCH/DELETEでリクエストされた場合にはsome_tokenが設定されているかを検証するようになり、/api/barのあらゆるHTTPメソッドでaccess_tokensテーブルに指定されたトークンがあるかを検証するようになります。

マッチしないパスやメソッドの場合はトークンの検証は行われません。

おわりに

実装するにあたって、下記のQiitaの記事をだいぶ参考にさせてもらいました。
わかりやすい記事をありがとうございます。

トークンを利用した認証・認可 API を実装するとき Authorization: Bearer ヘッダを使っていいのか調べた - Qiita

RFC規定に沿ってないところや、何か気が付いた点がありましたら、PRやIssueなどで教えてもらえると嬉しいです。