OAuth2と認証

Question

OAuth2と認証については多くの混乱が見られるため、混乱を解消するためにこの質問を作成しました。それでは、次の点について話しましょう。

認証と承認の違いは何ですか？
OAuth2は何をするつもりですか？
OAuth2暗黙的フローが認証に対して安全ではないのに、承認に対して安全なのはなぜですか（ヒント：アクセストークンは特定のクライアントにバインドされていません）
OAuth2暗黙的フローとOauth2認証コードフローの違いは何ですか？
OAuth2認証コードフローは認証に機能しますか？
認証にOAuth2ではなくOpenIDを使用する必要がありますか？
「OAuth2」フレームワークは認証と承認の両方に使用できるとグーグルが言っているのはなぜですか。

Google APIは、認証と承認にOAuth 2.0プロトコルを使用します。

https://developers.google.com/identity/protocols/OAuth2

OAuth2仕様： https://tools.ietf.org/html/rfc6749

Dimos · Accepted Answer

1.What is the difference between authentication and authorization?

Authenticationは、サーバーがユーザーが本当にそのユーザーであるかどうかを確認するプロセスです。これは通常、ユーザーがユーザー名とパスワードを指定したときに行われ、サーバーは、最初のユーザーがアカウントを作成したときに、データベースに格納されている資格情報（ユーザー名、パスワード）をチェックします。 Authorizationは、あるエンティティが別のエンティティにアクションを実行する許可を与えるときです。この場合、たとえば、別のWebサイトに保存および所有されているユーザーのデータにサイトがアクセスする必要がある場合です。

2.What is OAuth2 meant to do?

正式には、OAuth2は、認証サーバーのWebサイトASを介した認証後に、クライアントWebサイトCがリソースサーバーのWebサイトRSから自分のデータにアクセスできるようにする権限をユーザーに与えます。これはかなり複雑に見えるので、簡単にするために、一般的な例は、ユーザーがFacebookアカウントを使用してWebサイトにサインインする場合です。その場合、クライアントWebサイトとリソースサーバーWebサイトは同じで（C = RS =訪問したWebサイト）、認証サーバーはfacebook（AS = facebook）です。これは作成されたことに注意してください。これにより、C、RSはユーザーのパスワードを学習せず、ユーザーを認証できるようになります。

3.Why is OAuth2 implicit flow insecure for authentication while still secure for authorization?

暗黙的なフローの特異性は、アプリケーションに転送するためにアクセストークンがユーザーエージェントに与えられることです。そのため、リダイレクトURIのみに基づいています。したがって、クライアントシークレットの機密性がないため、このフローはアプリケーションのIDを認証しません（ユーザーおよびモバイルで実行されているアプリケーションに公開されるアクセストークン）。

4.What is the difference between OAuth2 implicit flow and Oauth2 authentication code flow and when to use which?

前述のように、暗黙のフローでは、アクセストークンはユーザーエージェントによってアプリケーションに転送されます。一方、認証コードフローでは、クライアントWebサーバーは最初に認証コードを取得し（リソースオーナー/ユーザーがアクセス権を付与した後）、次に認証コードを渡してAPI（clientID、secretID）を呼び出し、アクセストークン。これは、HTTP接続（SSL暗号化なし）の場合、中間者（ルーター、プロキシなど）がアクセストークンにアクセスできないようにするためです。したがって、前者はモバイルアプリケーションに適しており、後者はサーバー側アプリケーションに適しています。

5.Does OAuth2 authentication code flow work for authentication?

はい、認証コードフローは、認証サーバーを通じてユーザーも認証します。

6.Should you use OpenID instead of OAuth2 for authentication?

はい。

OpenIDは認証に使用されます。たとえば、ユーザーが単一の資格情報セットで複数のWebサイトにサインインできるようにする場合（サインオンサインオン）です。

OAuthは、前述のように認証に使用されます。 OAuthは、（上記の例のように、C = RS）承認を介して（疑似）認証を実行するためにわずかに調整できます。ただし、認証のみが必要な場合は、 OpenIDを使用できます。

7.Why is google saying that their "OAuth2" framework can be used for both authentication and authorization.

この設計決定の背後にある本当の理由は、対応するGoogleエンジニアだけが示すことができると思いますが、OpenIDとOAuthの両方を使用する代わりに、両方の使用法で単一のプロトコルを使用することを選択して、物事を簡素化したと考えられます。ただし、OAuthによる認証は、その人が所有するデータを介して認証することによって行われていることに注意してください。退屈な例は、自分の仕事の建物に入ろうとしている場合です。、従業員カードが明らかに私の首にあるため、私の資格情報については尋ねられません。これは、OAuthを介して認証が行われる方法であり、非常に単純化されています。そして、これが認証を実装する必要がある場合に備えて、承認のためにのみOAuthを使用してOpenIDを使用することが一般的に推奨される理由です。

OAuth for reference のさまざまなフローを説明する素敵なリンク

Gudradain · Answer

@RaptisDimosは良い答えを出しましたが、私はポイント＃3に費やすと思います。

OAuth2暗黙的フローが認証に対して安全ではないのに、承認に対して安全であるのはなぜですか？

認証にそれを使用しようとするときの暗黙的なフローの問題は、クライアントが直接アクセストークンを受け取り、そのアクセストークンが特定のクライアントにバインドされていないことです。これが意味することは、クライアントは、このトークンが彼または別のアプリケーション用であるかどうかを知らないということです。

このトークンは、所有者データへのアクセスに使用されます。所有者を「認証」するときは、通常、所有者のデータから所有者のメールをプルし、アプリケーション（クライアント）で認証します。 しかし、誰がそのアクセストークンをクライアントに渡したのかはわかりません。それが本当の所有者だったか、別のサービスをホストしている攻撃者でしたか？

攻撃の例

Client_Good：Google APIを使用して、暗黙のフローを使用してユーザーを認証する優れたクライアント
Client_Bad：Google APIを使用してClient_Goodを攻撃する悪意のあるクライアント

Client_Badは任意のサービスです。たとえば、Googleドライブに画像をアップロードできるWebアプリケーション。そのタスクを実行するには、Client_BadにGoogleからのアクセストークンが必要です。だから、あなたに彼に提供するように頼むでしょう。その後、そのサービスを使用して写真をアップロードできます。

あなたが知らなかったことは、写真をアップロードするためにClient_Badに与えたアクセストークンも、Client_Goodで自分を認証するために使用できる有効なアクセストークンであることです。これで、Client_Badの所有者がClient_Goodであなたになりすますことができます。 Client_Goodが重要なサービスだった場合、深刻な問題が発生する可能性があります。

なぜ認証が安全なのですか？

Client_Badにあなたに代わって写真をアップロードする権限を与えた場合、彼が直接それを実行しているか、それを実行するために別のサービスを通過しているかは問題ではないため、安全です。

たとえば、Googleドライブに画像をアップロードするだけの3つ目のクライアントClient_Pictureがあるとします。 Client_Badにアイテムをアップロードするように依頼すると、Client_BadはそのタスクをClient_Pictureに委任でき、同じ結果が得られたとしても気にしません。

さて、今では大量のサードパーティがデータにアクセスできるという事実がありますが、ここでも、Client_Badがこのアクセストークンを指定したときに、このアクセストークンを使用して何でもできることに同意しました。それはあなたの車の鍵を隣人に渡すようなものです。あなたは他の誰かにその車を使う権利を与えました、それから彼はしばらくの間それを別の隣人に貸してそれからあなたにそれを返すかもしれません。事はあなたが知らない、そしてあなたがコントロールを与えたときにあなたはそれに「同意」したということです。

注：誰かが説明を理解していないのか、何か間違ったことを言っているのかと思うことがあります...とにかく、それはセクション 10.16で説明されています OAuth2仕様の言い換えれば、それが役立つ場合。