OAuth の用語は長い間私を悩ませてきました。OAuth は、一部の人が言うように認可なのでしょうか、それとも認証なのでしょうか?
間違っていたら訂正してください。私は常に、承認とは誰かにリソースへのアクセスを許可する行為であると解釈してきましたが、OAuth には、特定のリソースへのユーザーのアクセスを実際に許可する実装はないようです。OAuth 実装で言及されているのは、ユーザーにトークン (署名され、場合によっては暗号化されている) を提供することだけです。このトークンは、その後、バックエンドのサービス エンドポイントへの呼び出しごとに渡され、そこで有効性がチェックされますが、これも OAuth の問題ではありません。
OAuth 認証 (どの記事でもそうではないと書かれていますが) では、ユーザーが資格情報を提供して、その資格情報によってユーザーがアクセスできるかどうかが証明されるものと思われますか?
つまり、OAuth は認可でも認証でもないようです。これらは他のプロセスによって実行する必要があるからです。では、OAuth とは一体何なのでしょうか? トークンを通信するためのプロセスなのでしょうか? 実際には特に意味のないくだらない言葉なのでしょうか?
このテーマについて、謎めいて迷信的な（幽霊や妖怪）印象を与えずに質問するのは難しいので、この質問に答えるのも簡単なことではないと思います。自己責任でご参加ください。
ベストアンサー1
OAuthは認証の仕様です
OAuth 2.0は認可のための仕様であり、認証のための仕様ではありません。RFC 6749、3.1. 認可エンドポイント明確に次のように述べています。
認可エンドポイントは、リソース所有者と対話し、認可許可を取得するために使用されます。認可サーバーは、最初にリソース所有者の身元を確認する必要があります。認可サーバーがリソース所有者を認証する方法（ユーザー名とパスワードのログイン、セッションCookieなど）は、この仕様の範囲外。
OAuth認証ですか?
認証は「その人が誰であるか」に関する情報を扱います。認可は「誰が誰にどのような権限を与えるか」に関する情報を扱います。認可フローの最初のステップとして認証が含まれます。これが、人々がよく混乱する理由です。
認証に OAuth 2.0 を使用するライブラリやサービスは数多くあります。これは「ソーシャル ログイン」と呼ばれることが多く、人々を混乱させます。「OAuth 認証」(「OAuth 認可」ではありません) と表示されている場合、それは認証に OAuth を使用するソリューションです。
オープンIDコネクト
OpenID 1.0 と OpenID 2.0 は認証の古い仕様です。仕様を作成した人たちは、認証には OpenID が使われるだろうと予想していました。しかし、認可ではなく認証に OAuth 2.0 を使う人も現れ、OAuth 認証が急速に普及しました。
OpenIDの人たちの視点から見ると、OAuthに基づく認証は十分に安全ではありませんでしたが、人々はOAuth認証を好んでいることを認めざるを得ませんでした。その結果、OpenIDの人たちは新しい仕様を定義することにしました。オープンIDコネクトOAuth 2.0 の上に構築されます。
はい、これによって人々はさらに混乱しました。
OAuth 2.0 と OpenID Connect の 1 文定義
OAuth2.0 とはサービスのユーザーが、自分の資格情報 (ID とパスワード) をアプリケーションに開示することなく、サービスでホストされている自分のデータにサードパーティのアプリケーションがアクセスできるようにできるフレームワークです。
オープンIDコネクトOAuth 2.0 上のフレームワークであり、サードパーティのアプリケーションがサービスによって管理されているユーザーの ID 情報を取得できます。
（申し訳ありませんが、これらの定義は概要私の会社のページ
実装者の観点からの定義
認証エンドユーザーの主体（＝一意の識別子）を判別するプロセスです。主体を判別する方法は多数あります。IDとパスワード、指紋、虹彩認識など。
承認サブジェクトを、要求された権限と権限を要求したクライアント アプリケーションに関連付けるプロセスです。アクセス トークンは関連付けを表します。