OAuth2 の何が良いのか、なぜそれを実装する必要があるのか説明してくれる人はいますか? 少し混乱しているので質問します。現在の私の考えは次のとおりです。
OAuth1 (より正確には HMAC) リクエストは論理的で、理解しやすく、開発しやすく、非常に安全であると思われます。
代わりに、OAuth2 では、認証リクエスト、アクセス トークン、リフレッシュ トークンが導入され、必要なデータを取得するには、セッションの開始時に 3 つのリクエストを行う必要があります。それでも、トークンの有効期限が切れると、リクエストの 1 つが最終的に失敗します。
そして、別のアクセス トークンを取得するには、アクセス トークンと同時に渡されたリフレッシュ トークンを使用します。セキュリティの観点からすると、アクセス トークンは無意味になるのでしょうか?
さらに、/r/netsec が最近示したように、SSL は完全に安全というわけではないので、すべてを安全な HMAC ではなく TLS/SSL に移行しようとする動きには困惑します。
OAuth は、100% の安全性ではなく、公開して完成させることが重要であると主張しています。プロバイダーの観点からは、それはあまり期待できる話ではありません。ドラフトで 6 つの異なるフローについて言及されているときに、何を達成しようとしているのかはわかりますが、私の頭の中ではうまくまとまりません。
実際に嫌いというよりは、その利点や理由を理解するのに苦労しているだけかもしれないので、これは少し不当な攻撃かもしれませんし、不満をぶちまけているように思われたら申し訳ありません。
ベストアンサー1
背景: OAuth 1.0a および 2.0 用のクライアント スタックとサーバー スタックを作成しました。
OAuth 1.0a と 2.0 はどちらも、サーバーがユーザーの ID を保証する2 段階認証と、サーバーがコンテンツ プロバイダーによってユーザーの ID を保証する3 段階認証をサポートしています。3 段階認証では、認可リクエストとアクセス トークンが役立ちますが、OAuth 1 にもこれらがあることに注意することが重要です。
複雑なもの：3本足の認証
OAuth 仕様の主なポイントは、コンテンツ プロバイダー(Facebook、Twitter など)がサーバー(クライアントに代わってコンテンツ プロバイダーと通信する Web アプリなど) に対して、クライアントが何らかの ID を持っていることを保証することです。3 レッグ認証では、クライアントやサーバーがその ID の詳細 (ユーザー名やパスワードなど) を知る必要がなく、これを実行できます。
OAuth の詳細にあまり深く立ち入ることなく (?) :
- クライアントはサーバーに承認要求を送信し、クライアントがそのサービスの正当なクライアントであることを検証します。
- サーバーは、リソースへのアクセスを要求できるようにクライアントをコンテンツ プロバイダーにリダイレクトします。
- コンテンツ プロバイダーはユーザーの ID を検証し、多くの場合、リソースにアクセスするための許可を要求します。
- コンテンツ プロバイダーはクライアントをサーバーにリダイレクトし、成功または失敗を通知します。この要求には、成功時の認証コードが含まれます。
- サーバーはコンテンツ プロバイダーに帯域外要求を行い、認証コードをアクセス トークンと交換します。
サーバーは、アクセス トークンを渡すことで、ユーザーに代わってコンテンツ プロバイダーにリクエストを送信できるようになりました。
各交換 (クライアント -> サーバー、サーバー -> コンテンツ プロバイダー) には共有シークレットの検証が含まれますが、OAuth 1 は暗号化されていない接続で実行できるため、各検証ではシークレットをネットワーク経由で渡すことはできません。
これは、ご指摘のとおり、HMAC で行われます。クライアントは、サーバーと共有するシークレットを使用して、認証要求の引数に署名します。サーバーは引数を受け取り、クライアントのキーを使用して署名し、正当なクライアントであるかどうかを確認できます (上記の手順 1)。
この署名では、クライアントとサーバーの両方が引数の順序に同意する必要があります (つまり、まったく同じ文字列に署名します)。OAuth 1 に関する主な不満の 1 つは、サーバーとクライアントの両方が同じように並べ替えて署名する必要があることです。これは扱いにくいコードであり、正しいか、ほとんど401 Unauthorized助けを借りずに取得するかのどちらかです。これにより、クライアントを作成するための障壁が高まります。
OAuth 2.0 では、認証リクエストを SSL 経由で実行する必要があるため、引数の並べ替えと署名がまったく不要になります。クライアントは秘密をサーバーに渡し、サーバーがそれを直接検証します。
サーバー -> コンテンツ プロバイダー接続にも同じ要件が存在し、これは SSL であるため、OAuth サービスにアクセスするサーバーを作成する際の障壁が 1 つ取り除かれます。
これにより、上記の手順 1、2、および 5 がはるかに簡単になります。
したがって、この時点で、サーバーにはユーザーのユーザー名/パスワードに相当する永続的なアクセス トークンがあります。サーバーは、そのアクセス トークンをリクエストの一部として (クエリ引数、HTTP ヘッダー、または POST フォーム データとして) 渡すことで、ユーザーに代わってコンテンツ プロバイダーにリクエストを行うことができます。
コンテンツ サービスへのアクセスが SSL 経由でのみ行われる場合、これで完了です。プレーン HTTP 経由で利用できる場合は、何らかの方法でその永続的なアクセス トークンを保護する必要があります。接続をスニッフィングする人は誰でも、ユーザーのコンテンツに永久にアクセスできるようになります。
OAuth 2 では、リフレッシュ トークンを使用してこの問題を解決しています。リフレッシュ トークンは永続的なパスワードと同等になり、SSL 経由でのみ送信されます。サーバーがコンテンツ サービスにアクセスする必要がある場合、リフレッシュ トークンを短期間のアクセス トークンと交換します。このようにして、スニッフィング可能なすべての HTTP アクセスは、期限切れになるトークンを使用して行われます。Google は、OAuth 2 API で 5 分間の有効期限を使用しています。
したがって、リフレッシュ トークンとは別に、OAuth 2 はクライアント、サーバー、コンテンツ プロバイダー間のすべての通信を簡素化します。リフレッシュ トークンは、コンテンツが暗号化されていない状態でアクセスされるときにのみセキュリティを提供するために存在します。
二足の認証
ただし、場合によっては、サーバーが自身のコンテンツへのアクセスを制御するだけでよいこともあります。2 段階認証を使用すると、クライアントはサーバーに対してユーザーを直接認証できます。
OAuth 2は、広く使用されていたOAuth 1の拡張機能を標準化します。私が最もよく知っているのは、Twitterによって導入されたものです。xAuthOAuth 2では次のように表示されます。リソース所有者のパスワード認証情報。
基本的に、ユーザーの資格情報 (ユーザー名とパスワード) をクライアントが信頼できる場合は、クライアントはそれらの資格情報をコンテンツ プロバイダーと直接交換してアクセス トークンを取得できます。これにより、モバイル アプリでの OAuth の有用性が高まります。3 段階認証では、コンテンツ サーバーで認証プロセスを処理するために HTTP ビューを埋め込む必要があります。
OAuth 1 では、これは公式標準の一部ではなく、他のすべてのリクエストと同じ署名手順が必要でした。
リソース所有者パスワード資格情報を使用して OAuth 2 のサーバー側を実装したところ、クライアントの観点からは、アクセス トークンの取得が簡単になりました。サーバーからアクセス トークンを要求し、クライアント ID/シークレットを HTTP Authorization ヘッダーとして渡し、ユーザーのログイン/パスワードをフォーム データとして渡します。
利点: シンプルさ
したがって、実装者の観点から見ると、OAuth 2 の主な利点は複雑さが軽減されることです。OAuth 2 では、厳密には難しいわけではないものの、確かに面倒なリクエスト署名手順は必要ありません。これにより、サービスのクライアントとして機能するために必要な作業が大幅に軽減されます。これは、(現代のモバイルの世界では) 最も手間を最小限にしたい部分です。サーバーからコンテンツ プロバイダーへの複雑さが軽減されるため、データセンターでのスケーラビリティが向上します。
また、現在広く使用されている OAuth 1.0a の拡張機能 (xAuth など) も標準に組み入れられています。