認証 (Authentication) と認可 (Authorization)

認証 (Authentication) と 認可 (Authorization) の違いは次のように要約できます：

完全な顧客アイデンティティとアクセス管理 (CIAM) の紹介については、CIAM シリーズを参照できます：

認証 (Authentication)

Logto は、さまざまなインタラクティブおよび非インタラクティブな認証 (Authentication) 方法をサポートしています。例えば：

サインイン体験：エンドユーザーのための認証 (Authentication) プロセス。
マシン間通信 (M2M) 認証 (Authentication)：サービスまたはアプリケーションのための認証 (Authentication) プロセス。

認証 (Authentication) の究極の目標は非常にシンプルです：エンティティ（Logto ではユーザーまたはアプリケーション）の一意の識別子を確認し取得することです。

Logto では、認可 (Authorization) はロールベースのアクセス制御 (RBAC) を通じて行われます。これにより、次のアクセスを管理するための完全なコントロールが可能になります：

これらの概念について詳しく知るには、次のリソースを参照してください：

これらの概念間の関係を視覚的に表現したものがこちらです：

要するに、認可 (Authorization) は「Identities」グループのエンティティが「Resources」グループのエンティティにアクセスできるかどうかを決定するルールを定義することです。

シングルサインオン (SSO) の性質上、Logto は現在、アプリケーションをリソースとして使用することをサポートしていません。代わりに、API リソースと権限を定義してリソースへのアクセスを制御できます。

前述のように、認証 (Authentication) はエンティティのアイデンティティを確認することであり、アクセス制御は認可 (Authorization) によって処理されます。したがって：

これは、Logto には「組織にサインインする」という概念がないことを意味します。ユーザーが認証 (Authentication) されると、定義された権限に基づいてすべてのリソース（組織リソースを含む）にアクセスする権限が与えられます。

このモデルは、認証 (Authentication) と認可 (Authorization) の問題を分離するため、効率的で明確です。GitHub や Notion などのすべての最新の SaaS アプリケーションは、このモデルに従っています。

ただし、ユーザーソースと組織の間に 1 対 1 のマッピングを確立する必要がある場合もあります。この場合、エンタープライズシングルサインオン (SSO) と組織のジャストインタイム (JIT) プロビジョニングが役立ちます。