認証と承認

Webアプリケーションのコンテキストの違いは何ですか？「auth」という略語がよく見られます。それがために立っていAUTH -enticationまたは認証 -orization？それとも両方ですか？

認証とは、誰かが本当に本人であることを確認するプロセスです。

承認とは、誰が何をすることが許可されているかを決定するルールを指します。たとえば、Adamはデータベースの作成と削除を許可されている一方、Usamaは読み取りのみを許可されています。

2つの概念は完全に直交で独立していますが、どちらもセキュリティ設計の中心であり、どちらかを正しく取得できないと、妥協の道が開かれます。

大まかに言えば、Webアプリに関して、認証とは、ログイン資格情報をチェックして、ユーザーがログインしていることを認識しているかどうかを確認することであり、承認とは、アクセス制御でユーザーに表示、編集、削除を許可するかどうかを調べることですまたはコンテンツを作成します。

要するに、お願いします。:-)

認証 =ログイン+パスワード（あなたは誰ですか）

承認 =権限（許可されていること）

短い「auth」は、最初の1つまたは両方を指す可能性が最も高いです。

承認対認証は、それを置きます：

認証は、システムがユーザーを安全に識別できるメカニズムです。認証システムは、質問に対する回答を提供します。

• ユーザーは誰ですか？
• ユーザーは本当に彼/彼女が彼自身を代表している人ですか？

対照的に、承認は、システムが制御するリソースを保護するために、特定の認証済みユーザーが持つ必要があるアクセスのレベルをシステムが決定するメカニズムです。たとえば、データベース管理システムは、特定の特定の個人にデータベースから情報を取得する機能を提供するが、データベースに格納されているデータを変更する機能は提供せず、他の個人にはデータを変更する機能を提供するように設計されている場合があります。承認システムは、質問に対する回答を提供します。

• ユーザーXはリソースRへのアクセスを許可されていますか？
• ユーザーXには操作Pを実行する権限がありますか？
• ユーザーXは、リソースRで操作Pを実行することを許可されていますか？

以下も参照してください。

• ウィキペディアでの認証と承認

私は認証と承認よりも検証と許可を好みます。

私の頭とコードでは、「検証」と「許可」について考える方が簡単です。

• 同じように聞こえない
• 同じ略語はありません

認証は検証であり、承認は許可をチェックしています。Authはどちらかを意味しますが、「ユーザー認証」、つまり「ユーザー認証」としてより頻繁に使用されます

2つの単語は似ているように聞こえ、概念は密接に関連し、一緒に使用されることが多いため、混乱は理解できます。また、前述のように、一般的に使用される略語Authは役に立ちません。

他の人は、認証と承認が何を意味するのかについてすでに説明しています。2つを明確に区別するための簡単なルールを次に示します。

• 認証entiカチオンを検証し、あなたのIdをenti TY（または信憑、あなたがそれを好む場合）
• 著者化は、あなたの検証著者アクセスする権利、すなわち、ITYをして、おそらく何かを変更します。

これを最も簡単な言葉で説明する画像を作成しようとしました

1）認証とは、「あなたが言っているのはあなたですか？」という意味です。

2）承認とは、「自分がしようとしていることを実行できるようにする必要があるか」という意味です。

これは下の画像でも説明されています。

私はそれを可能な限り最良の言葉で説明しようと試み、同じもののイメージを作成しました。

認証は、宣言されたIDを確認するプロセスです。

• 例：ユーザー名/パスワード

通常続い承認あなたはこれとそれを行うことができますことを承認され、。

• 例：権限

@Kerrekの答えに追加。

認証は一般化された形式です（すべての従業員がマシンにログインできます）

承認は特殊な形式です（ただし、管理者はマシンでのアプリケーションのインストール/アンインストールしかできません）

認証は、ログインのユーザー名とパスワードを確認するプロセスです。

承認は、何かにアクセスできることを確認するプロセスです。

定義

認証 -あなたはあなたが主張する人物ですか？

承認 -あなたがしようとしていることを何でもする権限がありますか？

例

ウェブアプリはGoogleログインを使用します。ユーザーがログインに成功すると、Googleから次のメッセージが返されます。

1. JWTトークン。これを検証およびデコードして、認証情報を取得できます。トークンはGoogleによって署名されていますか？ユーザーの名前と電子メールは何ですか？
2. アクセストークン。これは、許可ユーザーに代わってアクセスGoogleのAPIにウェブアプリを。たとえば、アプリはユーザーのGoogleカレンダーイベントにアクセスできますか？これらのアクセス許可は、要求されたスコープ、およびユーザーが許可したかどうかによって異なります。

さらに：

会社には、カスタマーサポートが会社のユーザーを管理できる管理ダッシュボードがある場合があります。カスタマーサポートがこのダッシュボードにアクセスできるようにするカスタムサインアップソリューションを提供する代わりに、会社はGoogleサインインを使用します。

JWTトークン（Googleサインインプロセスから受信）が会社の承認サーバーに送信され、ユーザーが組織のホストドメイン（email@company.com）のG Suiteアカウントを持っているかどうかがわかりますか？その場合、顧客サポートのために作成された会社のGoogleグループのメンバーですか？上記すべてに当てはまる場合は、認証済みと見なすことができます。

次に、会社の承認サーバーがダッシュボードアプリにアクセストークンを送信します。このアクセストークンを使用して、会社のリソースサーバーへの承認済みリクエストを作成できます（たとえば、会社のすべてのユーザーに送り返すエンドポイントにGETリクエストを作成する機能）。

Authentication 検証のプロセスです：

• システム内のユーザーID（ユーザー名、ログイン、電話番号、電子メール...）証明（秘密鍵、生体認証、SMSなど）を提供します。拡張機能としての多要素認証。
• 使用する電子メールチェック digital signature
• チェックサム

Authorizationはの次のステップAuthenticationです。これは、リソースに対する権限/役割/特権に関するものです。OAuth（Open Authorization）は承認の例です