OpenIDとは異なり、OAuth "pseudoauthentication"を使用することの欠点はありますか？
OAuthはOpenIDとは直交して異なるものです。OpenIDはユーザーの認証に関するものであり、OAuthは特定のサービスへのアクセス権の付与に関するものです。第三者に。
しかし、私は多くの人を知っています ここで示すように、とにかく認証としてOAuthを使用します ウィキペディアはそれを「疑似認証」と呼んでいますが、それは有効な方法のように見えますOpenIDを使用することに比べて欠点はありますか？OAuthが認証に問題がない場合、OAuthはOpenIDが行うすべてのことを実行できますが、OpenID OAuthは（サービスへのアクセスのように）行うことはできません。なぜ人々はOAuthではなく、OpenIDを使用するのでしょうか？
注：私は初心者なので、失礼し、ここで基本的なことを逃した場合は指摘してください。
OAuthは、アプリケーションYがユーザーYに属し、アプリケーションYが管理するリソース（「マイフォト」、「マイメールアドレス」、「マイカレンダー」など）へのアクセスが必要な場合のために設計されました—ユーザーAは、これらのリソースへのアクセスを許可できますアプリケーションYのリソースですが、アプリケーションXに実際のユーザー名/パスワードの資格情報を与えたくありません。そのため、アクセストークンは、アプリケーションYのリソースの代替認証情報として使用されます。アクセストークンは、ユーザー名/パスワード認証情報とは無関係に取り消すことができ、理想的には、特定のリソースへのアクセスのみを許可するように厳密にスコープ設定されています。
OAuth 2を使用して、危険な方法でモデル化された認証オーバーロードに使用します。上記の例を見て、認証に使用されていることを想像してください。アプリケーションXが認証にそのアクセストークンを使用している場合、アプリケーションYのリソースへのアクセスを許可するトークンを取得し、それを使用して独自のリソースへのアクセスを許可します。重要なのは、OAuth 2は、ユーザーが正常に認証されたことを意味します。問題は、アクセストークンがエンドユーザーが認証したアプリケーションについて何も言わないことですfor。したがって、アプリケーションZもアプリケーションY上のユーザーAのリソースのアクセストークン？アプリケーションZがアプリケーションXにこのアクセストークンを使用させることができる場合、アプリケーションZはユーザーAのリソースにアクセスできますアプリケーションX。これは悪いことです。ユーザーAはアプリケーションYのリソースにアクセスするためにアプリケーションZを信頼しましたが、ユーザーAは特定のアプリケーションZがアプリケーションXのリソースにアクセスすることに同意したことはありません。
OpenIDおよびOpenID Connectは、認証用に特別に設計されています。 OpenID Connectは、OAuth 2の上に構築されているため、既存の相互作用とフローを利用できますが、IDトークンと呼ばれるエンティティが追加されます。これは、一連のクレームを含むオブジェクトです。認証イベント。これらのクレームには、認証を実行したユーザーの識別子、認証を処理したサーバーの識別子、認証のaudienceの識別子が含まれます。これにより、アプリケーションに情報が提供されます。ユーザーに代わって認証されていることを検証する必要があります。
2つを比較するときはいつでも、openIDがパッシブであるアクティブとパッシブの識別/認証モデルの違いとして、OAuth active。
パッシブは、要求元のアプリケーションに、IDプロバイダーからアプリケーションにリダイレクトするWebブラウザーなど、何をすべきかを指示します。ブラウザーは、指示されたことだけを実行するため、基本的なダムクライアントです。アクティブでは、要求側のアプリケーションがデータを渡されたときに何をすべきかを知っている必要があり、データに対して必要なことをすべて実行します。トークン。
アクティブモデルでは、トークンがローカルに保存されているため、アプリケーションはユーザートークンを使用してAPIに直接リクエストを送信できます。パッシブモデルでは、ユーザーはプロバイダーへのリダイレクトを使用して認証し、一時的なトークンを使用してアプリケーションに戻る必要があります。 （技術的に一時的なものではありませんが、説明に適合します）
アプリケーションで何をしようとしているかに応じて、どちらのモデルでも機能します。
- OAuthは、認証プロトコルではなく、承認プロトコルです。認証方法としてOAuthを単独で使用することは、疑似認証と呼ばれることがあります。
- OpenIDは、認証プロトコルとして特別に設計されています。
重要な違いは、OpenID認証の使用例の場合、IDプロバイダーからの応答はIDのアサーションであるということです。 OAuth認可の使用例の場合、IDプロバイダーはAPIプロバイダーでもあり、IDプロバイダーからの応答は、アプリケーションへの継続的なアクセスを許可するアクセストークンです。ユーザーに代わってIDプロバイダーのAPIを使用します。アクセストークンは、アプリケーションがアイデンティティプロバイダーへのリクエストに含めることができる一種の「バレットキー」として機能します。これにより、ユーザーからこれらのAPIにアクセスするための権限があることが証明されます。
IDプロバイダーは通常（常にではありません）、OAuthアクセストークンを付与するプロセスの一部としてユーザーを認証するため、成功したOAuthアクセストークン要求を認証として表示するのは魅力的ですメソッド自体。ただし、OAuthはこの使用例を考慮して設計されていないため、この仮定を行うと、重大なセキュリティ上の欠陥が生じる可能性があります
