認可とは、リソースにアクセスする能力を与えるプロセスのことです。

もちろん、この定義は曖昧に聞こえるかもしれません。ですが、実生活のあらゆる状況に当てはめてみると、認可とは何かを説明しやすくなります。

住宅の所有権が良い例です。オーナーは、資産（リソース）への完全なアクセス権を持っていますが、他の人に資産へのアクセス権を付与することもできます。オーナーは、他の人が資産にアクセスすることを 認可します。このシンプルな例を使って、認可に関するいくつかの概念を説明することができます。

たとえば、家にアクセスすることは、許可です。つまり、リソースについて実行できるアクションです。家に関する他のアクセス許可には、家具を備えつけること、清掃すること、修理をすることなどがあります。

許可は、それが誰かに割り当てられると特権（または権利）となります。そのため、あなたが内装業者に家具を入れる許可を割り当てると、内装業者にその権限を与えることになります。

一方で、内装業者があなたの家に家具を入れる許可をたずねる場合もあります。この場合には、リクエストされた許可は、スコープです。つまり、内装業者があなたの家で実行したい「行動」ということになります。

場合によっては、認可はいくらか ID に関連しています。飛行機に搭乗するプロセスを考えてください。あなたは、その便を利用することが認められていることがわかる搭乗券を持っています。ただし、空港のゲート係員にとっては、搭乗券だけではあなたを搭乗させるわけにはいきません。あなたの ID を証明するパスポートも必要です。この場合、空港のゲート係員は、パスポートの名前と搭乗券の名前を比較し、適合していればあなたを通過させます。

認可の場合、あなたの名前は、ID の属性となります。他の属性は、年齢、言語、クレジットカード、特定のシナリオに関連するあらゆるものです。

パスポートに記載されているあなたの名前は、クレームです。つまり、その属性を取得していることを記載した宣言書です。パスポートの名前を読む人は、パスポートを発行した国を信頼しているため、あなたの名前について確信します。

搭乗者の ID と搭乗券は、フライトに乗るためのアクセス権限を付与する、「アクセストークン」のようなものです。

前述のシナリオでは、認可するという行為は、他のエンティティが完了させることができないタスクを、エンティティが実行できるようにすることでした。

認可を使うコンピューターシステムは、似たような方法で機能します。

コンピュータシステムにおいて、認可規則はIID およびアクセスの管理（IAM）と呼ばれる IT 規律の一部です。IAM において認証・認可は、誰がシステムのリソースにアクセスするのか、クライアント権限を設定するのかを、システム管理者が制御するのに役立ちます。IT システムが認可サービスを扱う方法は、実生活のアクセス制御プロセスとよく似ています。

Google Docs のようなコラボレーションツールについて考えてみましょう。

アプリケーションでは、文書を作成したり、共有したりすることができます。他のアクセス許可では、文書への更新、削除、コメントをすることができます。文書の所有者である場合には、誰か他の人とそれを共有して、1つまたは複数のポリシーを定義することができます。たとえば、コメントだけを残させるようにして、あなたの文書を他の誰かと共有することができます。

Iこの場合、:

リソース：文書

リソースオーナー：文書を作成するユーザー、文書のオーナー

許可されたユーザー：リソースオーナーによってコメントする権限を与えられたユーザー

次の図表では、リソースのアクセスに対する認可を示しています。:

アプリケーションのデプロイ中、コンピュータシステムは、複数の異なる認可戦略を利用します。最も有名なものは、役割ベースのアクセス制御（RBAC）属性ベースのアクセス制御（ABAC）です。近年、Auth0 は、関係性ベースのアクセス制御（ReBAC）に関する調査と解決に取り組んでいます。他にも多数の選択肢があり、それには次が含まれます グラフベースアクセス制御（Graph-Based Access Control） (GBAC) および 任意アクセス制御（Discretionary Access Control） (DAC)。これらの各戦略は、アプリケーション開発者が、異なる認可要件と認可サービスを取り扱う際に役立ちます。

ABAC を使う場合、コンピュータシステムは、ユーザーが、ユーザーに関連づけられた特性（属性またはクレーム）に基づき、アクションを実行するだけの十分なアクセス権限を持つかどうかを定義します。この認可プロセスのユースケースの例は、アルコール飲料を販売するオンラインストアです。オンラインストアのユーザーは、自身の年齢の証明書の登録や提供が必要です。認可においては、この場合、次のように説明することができます：

• オンラインストアは、リソースオーナーです

• アルコール飲料は、リソースです

• 登録プロセス中に認証された消費者の年齢はクレーム、つまり、ユーザー年齢という属性の証明書です

年齢の証明を提示することで、オンラインストアは、アルコールを購入するアクセスリクエストを処理することができます。ですから、この場合、リソースへのアクセスを許可する判断は、ユーザーの属性に基づいて行われます。

一方RBAC は、認可を役割に関連づけられた許可として扱い、直接ユーザーと関連づけません。** 役割**は、許可の集合にすぎません。たとえば、一組織の部長として働いていると想像してみてください。このような場合、たとえば、休暇申請や経費申請の承認、タスクの割り当てなど、部長には部長の役割に見合った権限が与えられているはずです。こうした許可を与えるためにシステム管理者は、まず、「管理者」（または類似した役割）と呼ばれる役割を作成します。続けて、これらの許可をこの役割に割り当て、それが「管理者」の役割と関連付けられます。もちろん、同じ許可セットを必要とする他のユーザーもその役割に関連付けることができます。

RBAC を使うメリットは、システム管理者がユーザーおよび許可を、個々に処理する必要がなく、まとめて処理できるため、より簡単に認可の特権を管理できることです。

関係性ベースのアクセス制御では、認可について次の質問を問うことになります。「このユーザーは、アクセスを可能にするほど、このオブジェクトやアクションと十分な関係があるか？」 関係性は、ユーザー属性から発生します。例えば、オブジェクトに関連する役割グループの一員である、または直接関係がある、或いは文書で共有されているなどです。時として、グループグラフ、役割、組織、オブジェクトをトラバースするには、多数のノードを探索し、ユーザーとユーザーがしようとしていることとの関係性を確立しなければなりません。関係性によって許可を取得する場合、どの関係性が重要かは、ReBAC システムの実装次第です。

Auth0 は、最近、ReBAC に基づいた次の Auth0 Fine Grained Authorization 製品のための開発者コミュニティプレビューをリリースしました。ファイングレインド認証（Fine Grained Authorization）についてのより詳しい情報は、当社の開発者プレビューをご覧ください。

[IAM 入門ページ]（https://auth0.com/intro-to-iam/）で、さらに多くの、ID とアクセスの管理に関するトピックをご覧ください。