あなたの Ruby アプリケーションに認証 (Authentication) を追加する

ヒント:

以下のデモンストレーションは Ruby 3.3.3 を基に構築されています。
サンプルプロジェクトは GitHub リポジトリで利用可能です。

前提条件

Logto Cloud アカウントまたはセルフホスト Logto。
Logto の従来の Web アプリケーションが作成されていること。

インストール

Logto SDK をバンドラーを通じてインストールします：

bundle add logto

または、お好みの方法で gem を追加してください。

統合

注記:

以下のデモンストレーションは Ruby on Rails 用です。ただし、他の Ruby フレームワークにも同じ手順を適用できます。

Logto クライアントを初期化する

Logto クライアントを初期化したいファイル（例：ベースコントローラーやミドルウェア）に、次のコードを追加します：

require "logto/client"

@client = LogtoClient.new(
  config: LogtoClient::Config.new(
    endpoint: "https://your-logto-endpoint.com",
    app_id: "your-logto-app-id",
    app_secret: "your-logto-app-secret"
  ),
  navigate: ->(uri) { a_redirect_method(uri) },
  storage: LogtoClient::SessionStorage.new(the_session_object)
)
end

例えば、Rails コントローラーでは、コードは次のようになります：

app/controllers/sample_controller.rb
require "logto/client"

class SampleController < ApplicationController
  before_action :initialize_logto_client

  private

  def initialize_logto_client
    @client = LogtoClient.new(
      config: LogtoClient::Config.new(
        # ...your configuration
      ),
      # クライアントが他のホスト（つまり、あなたの Logto テナント）にリダイレクトできるようにする
      navigate: ->(uri) { redirect_to(uri, allow_other_host: true) },
      # コントローラーはセッションオブジェクトにアクセスできる
      storage: LogtoClient::SessionStorage.new(session)
    )
  end
end

リダイレクト URI を設定する

詳細に入る前に、エンドユーザーの体験について簡単に説明します。サインインプロセスは次のように簡略化できます：

あなたのアプリがサインインメソッドを呼び出します。
ユーザーは Logto のサインインページにリダイレクトされます。ネイティブアプリの場合、システムブラウザが開かれます。
ユーザーがサインインし、あなたのアプリにリダイレクトされます（リダイレクト URI として設定されています）。

リダイレクトベースのサインインについて

この認証 (Authentication) プロセスは OpenID Connect (OIDC) プロトコルに従い、Logto はユーザーのサインインを保護するために厳格なセキュリティ対策を講じています。
複数のアプリがある場合、同じアイデンティティプロバイダー (Logto) を使用できます。ユーザーがあるアプリにサインインすると、Logto は別のアプリにアクセスした際に自動的にサインインプロセスを完了します。

リダイレクトベースのサインインの理論と利点について詳しく知るには、Logto サインイン体験の説明を参照してください。

注記:

以下のコードスニペットでは、あなたのアプリが http://localhost:3000/ で実行されていると仮定しています。

リダイレクト URI を設定する

Logto Console のアプリケーション詳細ページに移動します。リダイレクト URI http://localhost:3000/callback を追加します。

サインインと同様に、ユーザーは共有セッションからサインアウトするために Logto にリダイレクトされるべきです。完了したら、ユーザーをあなたのウェブサイトに戻すと良いでしょう。例えば、http://localhost:3000/ をサインアウト後のリダイレクト URI セクションとして追加します。

その後、「保存」をクリックして変更を保存します。

コールバックを処理する

リダイレクト URI が http://localhost:3000/callback に設定されているため、アプリケーションで処理する必要があります。Rails コントローラーでは、次のコードを追加できます：

app/controllers/sample_controller.rb
class SampleController < ApplicationController
  def callback
    @client.handle_sign_in_callback(url: request.original_url)
  end
end

そして、config/routes.rb にルートを設定します：

config/routes.rb
Rails.application.routes.draw do
  get "/callback", to: "sample#callback"
end

サインインとサインアウトを呼び出す

アプリケーションでサインインとサインアウトを呼び出す方法はさまざまです。例えば、Rails アプリケーションに 2 つのルートを実装できます：

app/controllers/sample_controller.rb
class SampleController < ApplicationController
  def sign_in
    @client.sign_in(redirect_uri: request.base_url + "/callback")
  end

  def sign_out
    @client.sign_out(post_logout_redirect_uri: request.base_url)
  end

  # ...
end

config/routes.rb
Rails.application.routes.draw do
  get "/sign_in", to: "sample#sign_in"
  get "/sign_out", to: "sample#sign_out"

  # ...
end

次に、ビューにボタンやリンクを作成して、これらのアクションをトリガーできます。例えば：

app/views/sample/index.html.erb
<% if @client.is_authenticated? %>
  <a href="<%= sign_out_path %>">Sign out</a>
<% else %>
  <a href="<%= sign_in_path %>">Sign in</a>
<% end %>

チェックポイント: アプリケーションをテストする

これで、アプリケーションをテストできます：

アプリケーションを実行すると、サインインボタンが表示されます。
サインインボタンをクリックすると、SDK がサインインプロセスを初期化し、Logto のサインインページにリダイレクトされます。
サインインすると、アプリケーションに戻り、サインアウトボタンが表示されます。
サインアウトボタンをクリックしてローカルストレージをクリアし、サインアウトします。

ユーザー情報を取得する

ユーザー情報の表示

ユーザーの情報を表示するには、@client.id_token_claims メソッドを使用できます。例えば、ビューで：

app/views/sample/index.html.erb
<% if @client.is_authenticated? %>
  <p>ようこそ, <%= @client.id_token_claims["name"] %></p>
<% else %>
  <p>サインインしてください</p>
<% end %>

詳細については、gemdocs の #id_token_claims メソッドを参照してください。

追加のクレーム (Claims) をリクエストする

id_token_claims から返されるオブジェクトに一部のユーザー情報が欠けていることがあります。これは、OAuth 2.0 と OpenID Connect (OIDC) が最小特権の原則 (PoLP) に従うように設計されており、Logto はこれらの標準に基づいて構築されているためです。

デフォルトでは、限られたクレーム (Claim) が返されます。より多くの情報が必要な場合は、追加のスコープ (Scope) をリクエストして、より多くのクレーム (Claim) にアクセスできます。

備考:

「クレーム (Claim)」はサブジェクトについての主張であり、「スコープ (Scope)」はクレーム (Claim) のグループです。現在のケースでは、クレーム (Claim) はユーザーに関する情報の一部です。

スコープ - クレーム (Claim) 関係の非規範的な例を示します：

ヒント:

「sub」クレーム (Claim) は「サブジェクト (Subject)」を意味し、ユーザーの一意の識別子（つまり、ユーザー ID）です。

Logto SDK は常に 3 つのスコープ (Scope) をリクエストします：openid、profile、および offline_access。

追加のスコープ (Scopes) をリクエストするには、LogtoClient::Config オブジェクトで scopes オプションを設定します：

require "logto/client"

@client = LogtoClient.new(
  config: LogtoClient::Config.new(
    # ...他の設定
    scopes: ["email", "phone"] # 必要に応じてスコープを追加
  ),
  # ...他の設定
)

その後、id_token_claims を介して追加のクレーム (Claims) にアクセスできます：

app/views/sample/index.html.erb
<% if @client.is_authenticated? %>
  <p>名前: <%= @client.id_token_claims["name"] %></p>
  <p>メール: <%= @client.id_token_claims["email"] %></p>
  <p>電話: <%= @client.id_token_claims["phone"] %></p>
<% else %>
  <p>サインインしてください</p>
<% end %>

ネットワークリクエストが必要なクレーム (Claims)

ID トークンの肥大化を防ぐために、一部のクレーム (Claims) は取得するためにネットワークリクエストが必要です。例えば、custom_data クレームはスコープで要求されてもユーザーオブジェクトに含まれません。これらのクレームにアクセスするには、 fetch_user_info メソッドを使用できます：

app/views/sample/index.html.erb
<% if @client.is_authenticated? %>
<p>カスタムデータ: <%= @client.fetch_user_info["custom_data"] %></p>
<!-- ... -->

このメソッドは、userinfo エンドポイントにリクエストを送信してユーザー情報を取得します。利用可能なスコープとクレームについて詳しくは、スコープとクレームのセクションを参照してください。

スコープ (Scopes) とクレーム (Claims)

Logto は OIDC のスコープとクレームの規約を使用して、ID トークンおよび OIDC userinfo エンドポイントからユーザー情報を取得するためのスコープとクレームを定義します。「スコープ」と「クレーム」は、OAuth 2.0 および OpenID Connect (OIDC) 仕様からの用語です。

サポートされているスコープと対応するクレーム (Claims) のリストはこちらです：

openid

クレーム名	タイプ	説明	ユーザー情報が必要か？
sub	`string`	ユーザーの一意の識別子	いいえ

profile

クレーム名	タイプ	説明	ユーザー情報が必要か？
name	`string`	ユーザーのフルネーム	いいえ
username	`string`	ユーザーのユーザー名	いいえ
picture	`string`	エンドユーザーのプロフィール写真の URL。この URL は、画像を含む Web ページではなく、画像ファイル（例えば PNG、JPEG、または GIF 画像ファイル）を指す必要があります。この URL は、エンドユーザーを説明する際に表示するのに適したプロフィール写真を特に参照するべきであり、エンドユーザーが撮影した任意の写真を参照するべきではありません。	いいえ
created_at	`number`	エンドユーザーが作成された時間。時間は Unix エポック（1970-01-01T00:00:00Z）からのミリ秒数で表されます。	いいえ
updated_at	`number`	エンドユーザーの情報が最後に更新された時間。時間は Unix エポック（1970-01-01T00:00:00Z）からのミリ秒数で表されます。	いいえ

その他の標準クレームには、family_name、given_name、middle_name、nickname、preferred_username、profile、website、gender、birthdate、zoneinfo、および locale が含まれ、ユーザー情報エンドポイントを要求することなく profile スコープに含まれます。上記のクレームと異なる点は、これらのクレームは値が空でない場合にのみ返されることであり、上記のクレームは値が空の場合に null を返します。

注記:

標準クレームとは異なり、created_at と updated_at クレームは秒ではなくミリ秒を使用しています。

email

クレーム名	タイプ	説明	ユーザー情報が必要か？
email	`string`	ユーザーのメールアドレス	いいえ
email_verified	`boolean`	メールアドレスが確認済みかどうか	いいえ

phone

クレーム名	タイプ	説明	ユーザー情報が必要か？
phone_number	`string`	ユーザーの電話番号	いいえ
phone_number_verified	`boolean`	電話番号が確認済みかどうか	いいえ

address

住所クレームの詳細については、OpenID Connect Core 1.0 を参照してください。

custom_data

クレーム名	タイプ	説明	ユーザー情報が必要か？
custom_data	`object`	ユーザーのカスタムデータ	はい

identities

クレーム名	タイプ	説明	ユーザー情報が必要か？
identities	`object`	ユーザーのリンクされたアイデンティティ	はい
sso_identities	`array`	ユーザーのリンクされた SSO アイデンティティ	はい

urn:logto:scope:organizations

クレーム名	タイプ	説明	ユーザー情報が必要か？
organizations	`string[]`	ユーザーが所属する組織の ID	いいえ
organization_data	`object[]`	ユーザーが所属する組織のデータ	はい

urn:logto:scope:organization_roles

クレーム名	タイプ	説明	ユーザー情報が必要か？
organization_roles	`string[]`	ユーザーが所属する組織のロールで、`<organization_id>:<role_name>` の形式	いいえ

パフォーマンスとデータサイズを考慮して、「ユーザー情報が必要か？」が「はい」の場合、クレームは ID トークンに表示されず、ユーザー情報エンドポイントのレスポンスで返されます。

API リソースと組織

まず 🔐 ロールベースのアクセス制御 (RBAC) を読むことをお勧めします。これにより、Logto の RBAC の基本概念と API リソースを適切に設定する方法を理解できます。

Logto クライアントを設定する

API リソースを設定したら、アプリで Logto を設定する際にそれらを追加できます：

require "logto/client"

@client = LogtoClient.new(
  config: LogtoClient::Config.new(
    # ...other configurations
    resources: ["https://shopping.your-app.com/api", "https://store.your-app.com/api"] # API リソースを追加
  ),
  # ...other configurations
)

各 API リソースには独自の権限 (スコープ) があります。

例えば、https://shopping.your-app.com/api リソースには shopping:read と shopping:write の権限があり、https://store.your-app.com/api リソースには store:read と store:write の権限があります。

これらの権限を要求するには、アプリで Logto を設定する際にそれらを追加できます：

require "logto/client"

@client = LogtoClient.new(
  config: LogtoClient::Config.new(
    # ...other configurations
    scopes: ["shopping:read", "shopping:write", "store:read", "store:write"],
    resources: ["https://shopping.your-app.com/api", "https://store.your-app.com/api"]
  ),
  # ...other configurations
)

スコープが API リソースとは別に定義されていることに気付くかもしれません。これは、OAuth 2.0 のリソースインジケーターが、リクエストの最終的なスコープはすべてのターゲットサービスでのすべてのスコープの直積になると指定しているためです。

したがって、上記のケースでは、Logto での定義からスコープを簡略化できます。両方の API リソースは、プレフィックスなしで read と write スコープを持つことができます。その後、Logto の設定では：

require "logto/client"

@client = LogtoClient.new(
  config: LogtoClient::Config.new(
    # ...他の設定
    scopes: ["read", "write"],
    resources: ["https://shopping.your-app.com/api", "https://store.your-app.com/api"]
  ),
  # ...他の設定
)

各 API リソースは、read と write の両方のスコープを要求します。

注記:

API リソースで定義されていないスコープを要求しても問題ありません。例えば、API リソースに email スコープが利用できなくても、email スコープを要求できます。利用できないスコープは安全に無視されます。

サインインが成功すると、Logto はユーザーのロールに応じて適切なスコープを API リソースに発行します。

API リソースのためのアクセストークンを取得する

特定の API リソースのアクセストークンを取得するには、access_tpken メソッドを使用できます：

token = @client.access_token(resource: "https://shopping.your-app.com/api")

このメソッドは、ユーザーが関連する権限を持っている場合に API リソースにアクセスするために使用できる JWT アクセストークンを返します。現在キャッシュされているアクセストークンが期限切れの場合、このメソッドは自動的にリフレッシュトークンを使用して新しいアクセストークンを取得しようとします。

組織トークンを取得する

組織 (Organization) が初めての場合は、🏢 組織 (マルチテナンシー) を読んで始めてください。

Logto クライアントを設定する際に、LogtoCore::USER_SCOPE[:organizations] スコープを追加する必要があります：

require "logto/core"
require "logto/client"

@client = LogtoClient.new(
  config: LogtoClient::Config.new(
    # ...他の設定
    scopes: [LogtoCore::USER_SCOPE[:organizations]]
  ),
  # ...他の設定
)

ユーザーがサインインしたら、ユーザーのための組織トークンを取得できます：

token = @client.access_token(organization_id: "organization_id")

組織 API リソース

組織内の API リソースのアクセストークンを取得するには、access_token メソッドを使用し、API リソースと組織 ID の両方をパラメーターとして指定します：

token = @client.access_token(
  api_resource: "https://shopping.your-app.com/api",
  organization_id: "organization_id"
)

さらなる読み物

エンドユーザーフロー：認証 (Authentication) フロー、アカウントフロー、組織フローコネクターを設定するあなたの API を保護する

前提条件​

インストール​

統合​

Logto クライアントを初期化する​

リダイレクト URI を設定する​

リダイレクトベースのサインインについて​

リダイレクト URI を設定する​

コールバックを処理する​

サインインとサインアウトを呼び出す​

チェックポイント: アプリケーションをテストする​

ユーザー情報を取得する​

ユーザー情報の表示​

追加のクレーム (Claims) をリクエストする​

ネットワークリクエストが必要なクレーム (Claims)​

スコープ (Scopes) とクレーム (Claims)​

API リソースと組織​

Logto クライアントを設定する​

API リソースのためのアクセス トークンを取得する​

組織トークンを取得する​

組織 API リソース​

さらなる読み物​

前提条件

インストール

統合

Logto クライアントを初期化する

リダイレクト URI を設定する

リダイレクトベースのサインインについて

リダイレクト URI を設定する

コールバックを処理する

サインインとサインアウトを呼び出す

チェックポイント: アプリケーションをテストする

ユーザー情報を取得する

ユーザー情報の表示

追加のクレーム (Claims) をリクエストする

ネットワークリクエストが必要なクレーム (Claims)

スコープ (Scopes) とクレーム (Claims)

API リソースと組織

Logto クライアントを設定する

API リソースのためのアクセストークンを取得する

組織トークンを取得する

組織 API リソース

さらなる読み物