Logto の認可システムとアイデンティティ管理シナリオでのその利用

Logto は認証プロバイダーとしてだけでなく、認可プロバイダーとしても機能します。この記事では、Logto の認可方法の概要を提供し、これらの柔軟な層がさまざまなシナリオにどのように適用できるかを説明します。

ロールベースのアクセス制御を使用して API リソースを保護する#

Logto に API リソースを登録する#

異なるユーザーがリソースとアクションの権限に異なるアクセス権を持つ認可システムを構築するには、Logto に API リソースを登録し、権限を追加することから始めます。これらの権限を単一の API または複数の API に集約するために、ロールを利用します。

Logto の優れた機能の一つには、ユーザーやマシン間のアプリケーションを含む異なるエンティティに適用できるさまざまなタイプのロールを作成できる能力があります。ユーザーはユーザー固有のロールを継承することができ、マシン間のアプリケーションはそれ専用に設計されたロールを継承できます。

対象のエンティティ：ユーザー#

アプリが一般的なアプリケーションであり、異なるユーザーが異なるアクションを実行する必要がある場合、ユーザーロールを活用することは、効果的なアクセスコントロールシステムを確立する柔軟な方法です。

対象のエンティティ：マシン間のアプリケーション#

マシン間 (M2M) は、リソースと直接やり取りする必要があるアプリがある場合に一般的な認証方法です。例えば、Logto でユーザーのカスタムデータを更新する API サービスや、日々の注文を取得する統計サービスなどです。

Logto では、マシン間のアプリケーションを 2 つの主要なユースケースで利用できます。

1. ヘッドレス API アプリを保護するために認可システムを構築する。
2. Logto 管理 API を使用してあなたのサービスを開発し、エンドユーザーが自分のアイデンティティ関連情報を更新できるユーザープロファイルを可能にします。

このコンテキストでのユーザーロールとの違いは、ロールが特にマシン間のロールとして定義されており、ユーザーロールではないため、マシン間のアプリケーションにのみ割り当てられることです。

この API RBAC コンテキストでは、API リソース、ロール、権限は「民主化」され、統一されたアイデンティティシステム内のシステムレベルで表示されます。このアプローチは、複雑な階層管理があまり必要でない、単純な B2C プロダクトでは非常に一般的です。

組織テンプレート (RBAC) を使用して組織レベルのリソースを保護する#

B2B シナリオでは、ユーザーロールは異なる組織で異なる場合があります。例えば、ジョンは組織 A では管理者ロールを持ちますが、組織 B ではメンバーロールしか持たないかもしれません。

これは Logto で組織テンプレートを設定することによって実現でき、あなたのマルチテナントアプリのアクセスコントロールシステムの構築を支援します。

多数のロールを各組織のために作成する代わりに、Logto では組織テンプレートを作成することを可能にします。このアプローチはすべての組織間での一貫性を維持しつつ、ユーザーが異なる組織で異なるロールを持つ柔軟性を提供します。

組織権限は API リソースを登録する必要はありません。Logto は組織トークンを発行し、ロールや他のクレームを含住し、API での組織トークンのさらなる検証にも使用できます。

組織テンプレート (RBAC) を使用してシステムおよび組織レベルのリソースの両方を保護する#

Logto に API リソースを登録しており、その利用を組織レベルに拡張したい場合、それは完全に可能です。

これが必要になるのは、システムレベルの機能と組織固有の操作の両方で同じエンドポイントを使用している場合です。単一のエンドポイントは問題ありませんし、組織コンテキストを活用することでテナントの分離も効果的に確保できます。

Logto では、API 権限を直接組織の役割に割り当て、特定の要件に応じて調整することができます。

API 権限を組織の役割にどのように統合するかを簡単に見てみましょう。

この機能は開発中であり、2024 年の前半に利用可能になると期待されています。

Logto の認可システムと今後の認可機能にわくわくしていますか？サインアップして、最新の製品アップデートをすぐに手に入れましょう。