メインコンテンツまでスキップ

認可 (Authorization)

Logto の 認可 (Authorization) では、認証 (Authentication) 後にユーザーやアプリが何をできるか、つまり各アイデンティティに対してどの API、リソース、アクションが許可されているかを定義します。

Logto は、現代の SaaS や AI アプリ向けに柔軟なトークンベースの認可 (Authorization) を提供します。API リソースをグローバルに、または各組織 (Organization) のコンテキスト内で保護できます。すべての権限は ロールベースのアクセス制御 (RBAC) システムで管理され、組織テンプレート によってマルチテナントアプリにも高度に対応しています。

コア概念

  • ロールベースのアクセス制御 (RBAC): Logto は RBAC を基盤とし、ユーザー、クライアント、サービスへの権限割り当てを行います。RBAC について詳しくはこちら
  • API リソース: 保護したいバックエンドサービスやエンドポイント(グローバルまたは組織固有)。
  • ロール (Role): 権限 (Permissions) のグループ(例:管理者、閲覧者、編集者)。
  • 権限 (Permission)(スコープ (Scope)): 許可された特定のアクション(例:read:reportinvite:member)。
  • 組織 (Organization): アプリケーション内のテナント、ワークスペース、顧客を表します。これは Logto テナント(全体の Logto プロジェクトやインスタンス)とは異なります。
  • 組織テンプレート: マルチテナントアプリ向けに、すべての組織に適用できる再利用可能なロールと権限のセットを定義します。組織テンプレートの仕組みはこちら
  • アクセス トークン / 組織トークン: グローバルまたは組織スコープの権限 (Permissions) を含むクレーム (Claims) を持つトークン。

認可 (Authorization) シナリオ

Logto には主に 3 つの認可 (Authorization) パターンがあります。ニーズに合ったシナリオを選択してください:

シナリオ使用タイミングトークン種別ロール設定詳細はこちら
グローバル API リソース権限Logto テナント全体で共有される API リソースを保護(組織固有でない場合)アクセス トークングローバルロール/権限を割り当てグローバル API リソースの保護
組織(非 API)権限組織固有のアクション、UI 機能、ビジネスロジックの制御(API 以外)組織トークンアプリ制御用の組織ロール/権限を割り当て組織(非 API)権限の保護
組織レベル API リソース権限特定の組織内でアクセス可能な API リソースを保護組織トークン組織 API 用の組織ロール/権限を割り当て組織レベル API リソースの保護

Logto は RFC 8707 に従い、OAuth 2.0 認可フローで resource パラメーターを使用して API リソースをモデル化します。これにより、複数の API やマイクロサービスのセキュリティ確保が容易になり、他の標準ベースのシステムとも互換性が保たれます。

ヒント:

カスタムクレーム (Claims) や高度なアクセス制御が必要ですか?カスタムトークンクレーム をご覧ください。

Logto の認可 (Authorization) の仕組み

  • トークンベース: すべてのアクセスは安全に署名されたアクセス トークンによって許可されます。バックエンドでトークンを検証し、権限 (スコープ) を強制します。

  • グローバル vs. 組織権限 (スコープ):

    • グローバル 権限 (スコープ):Logto テナント全体で API リソースへのアクセスを制御します。
    • 組織 権限 (スコープ):組織コンテキスト内でビジネスロジック(アプリ機能)や API リソースの両方を制御します。組織権限は、API 以外の機能(UI 要素やワークフローなど)や組織スコープの API エンドポイントにも適用できます。
  • ロールと権限 (スコープ): ロールは権限 (スコープ) の集合体です。シナリオに応じて、ユーザーやクライアントにグローバルまたは組織単位でロールを割り当てます。

次のステップ

さらに進みたい方は、実践的なガイドや理解を深めるためのリソースをご覧ください:

ユースケース

実践的な例や現実的なシナリオをお探しですか?以下のガイドをご覧ください:

さらに読む

RBAC と ABAC:知っておくべきアクセス制御モデル JWT を使うべきタイミングとは? API 認可 (Authorization) の方法