OAuth承認と認証

Question 1

OAuthの用語は、私を長い間悩ませてきました。OAuth認証は、一部の人が示唆しているようにですか、それとも認証ですか？

私が間違っている場合は訂正してください。ただし、承認は誰かにリソースへのアクセスを許可する行為であると常に読んでいますが、OAuthには、特定のリソースへのユーザーへのアクセスを実際に許可する実装がないようです。すべてのOAuth実装は、ユーザーにトークン（署名され、場合によっては暗号化されたもの）を提供することについて話します。このトークンは、バックエンドサービスエンドポイントへのすべての呼び出しで渡され、そこで有効性がチェックされます。これもOAuthの問題ではありません。

私が取るOAuth認証（すべての記事はそうではないと言っています）は、ユーザーが資格情報を提供する必要があり、それはユーザーがアクセスできるべき/すべきでないことを証明しますか？

したがって、OAuthは他のプロセスによって実行される必要があるため、承認NOR認証ではないようです。それで、一体何ですか？トークンを伝達するためのプロセスですか？本当に意味のない綿毛の言葉ですか？

謎めいた迷信（魔界村）に聞こえずにこのテーマについて質問するのは難しいので、この質問に答えるのも簡単なことではないと思います。ご自身の責任でご入場ください。

Question 2

OAuthは承認の仕様です

OAuth 2.0は承認の仕様ですが、認証の仕様ではありません。RFC 6749、3.1 。承認エンドポイントは明示的に次のように述べています。

承認エンドポイントは、リソース所有者と対話し、承認付与を取得するために使用されます。承認サーバーは、最初にリソース所有者のIDを確認する必要があります。承認サーバーがリソース所有者を認証する方法（ユーザー名とパスワードのログイン、セッションCookieなど）は、この仕様の範囲を超えています。

OAuth認証？

認証は「誰であるか」に関する情報を扱います。承認は、「誰が誰にどの許可を与えるか」に関する情報を扱います。承認フローには、最初のステップとして認証が含まれます。それが人々がしばしば混乱する理由です。

認証にOAuth2.0を使用するライブラリやサービスはたくさんあります。これは「ソーシャルログイン」と呼ばれることが多く、人々をより混乱させます。「OAuth認証」（「OAuth認証」ではない）が表示されている場合、それは認証にOAuthを使用するソリューションです。

OpenIDコネクト

OpenID1.0およびOpenID2.0は、認証の古い仕様です。仕様を作成した人は、認証にOpenIDを使用することを期待していました。ただし、一部の人々は認証（承認用ではない）にOAuth 2.0を使用し始め、OAuth認証が急速に普及しました。

OpenIDの人の観点からは、OAuthに基づく認証は十分に安全ではありませんでしたが、人々がOAuth認証を好むことを認めなければなりませんでした。その結果、OpenIDの担当者は、OAuth2.0に加えて新しい仕様であるOpenIDConnectを定義することにしました。

はい、これは人々をはるかに混乱させました。

OAuth2.0とOpenIDConnectの1文の定義

OAuth 2.0は、サービスのユーザーが、サードパーティのアプリケーションが自分の資格情報（IDとパスワード）をアプリケーションに公開することなく、サービスでホストされている自分のデータにアクセスできるようにするフレームワークです。

OpenID Connectは、サードパーティアプリケーションがサービスによって管理されるユーザーのID情報を取得できるOAuth2.0上のフレームワークです。

^{（申し訳ありませんが、これらの定義は私の会社の概要ページからの抜粋です）}

実装者の観点からの定義

認証は、エンドユーザーのサブジェクト（=一意の識別子）を決定するプロセスです。主題を決定する多くの方法があります。IDとパスワード、指紋、虹彩認識など。

承認は、サブジェクトを要求されたアクセス許可およびアクセス許可を要求したクライアントアプリケーションに関連付けるプロセスです。アクセストークンは関連付けを表します。