目的
最近、PaaSプラットフォームの責任者は、サービスプロバイダの開発者の多くをドッキング、承認プロセスをドッキングの過程で人々は、多くの問題が発生し、成功したアクセスの前に多くのフラストレーションを経験しました。
もちろん、主な理由は、システムが友好的ではなく、大多数の開発者にとって穴を掘ってしまったからであり、常に改善する方法を見つけ続けるでしょう。
OAuth 2.0を十分に理解していなければ、認証システムを設計する作業は、無意識のうちにOAuth 2.0ライブラリの劣ったバージョンを設計することになる可能性が高い、というのは有名な話です。
この記事では、OAuth2.0について深く考えることで、原理原則の理解を深め、OAuth2.0プロセスの甌穴をより少なく踏めるようになればと思います。今後、認証プロセスを設計する過程で、冗長な設計を減らすこともできるでしょう。
アドバンスノート
この記事は、OAuth 2.0のソリューションフローの詳細な説明というよりは、思考プロセスの説明です。
OAuth2.0スキームの説明を知りたい方は、 rfc4769お読みください。
思考プロセス
認証コードモード、簡易モード、パスワードモード、クライアントモードの4つのモードがあります。
これらのうち、簡易モード、パスワードモード、クライアントモード 最も安全な方法は、このような実行可能な認証プロセスを提供することとしか言いようがありません。
日常的には、内部システムの小さなライブラリを除けば、oAuth 2.0の認証コードモデルを使用することがほとんどです。
認証コードモデルは、情報の相互信頼の問題に対処するために設計されています：
- ユーザー：どのサービス・プロバイダーにどのような情報を許可すればよいですか？
- サービスプロバイダー：どのユーザーがどの情報を私に許可しましたか？
- 承認者：誰が、私からどのサービスプロバイダーへ承認情報を要求しますか？
以上の説明から、各当事者には2つの重要な情報が欠けていることがわかります。
次に、3つの当事者と関連する情報に番号を付けます。
ユーザー：私がどのサービスプロバイダーからどのような情報を承認するか、サービスプロバイダー：どのユーザーが私にどのような情報を承認するか、承認者：誰が私からどのサービスプロバイダーへの情報の承認を要求するか；
ラベルを貼ったら、関連する情報の相関関係を調べます：
ユーザーはb1とc1
a1とc2を提供します。
auth は a2 と b2 を提供できます。
b1とc1は等価、a1とc2は等価、a2とb2は等価。
要旨には3つの重要なメッセージがあるだけです：
- どのサービスプロバイダ
- 認証情報とは
- 認可情報とは
三者が互いに重要な情報を提供し合う依存関係にある場合、プロセスはどのように設計されるのでしょうか？
OAuth2.0はすでに完全なプログラムを持っており、次に、oAuth2.0の認証コード・モード・プロセスを分解する問題があります。
上記のフローチャートは、tools.ietf.org/html/rfc674...より引用。
. ユーザはログインするためにユーザブリングでサードパーティのアプリケーションを選択します；
. ページがジャンプした後、githubはユーザーにログインを求め、クライアントに権限を与えるかどうかを尋ね、ユーザーはAgreeをクリックします；
. github return 認証コード return to redirect_url ；
. クライアントがURLから認証コードを取得したら、バックエンドのgithubサーバーにトークンをリクエストすることができます；
. github AccessToken を返し、必要に応じて RefreshToken を追加します；
標準的なプロセスには5つのステップがあります。 省略することは可能ですか？
情報を組み合わせ、分析を続けるための思考ポイント：
ステップ A と B はメッセージ a1、a2、c1、c2、user と auth の相互接続、user と corp の相互接続の必要な相互作用を完了します；
ステップ C の認証コードは情報 a2 と b2 を提供し、redirect_url は情報 a1 と c2 を提供し、認証と corp の相関関係を完成させます；
ステップ D と E では、最終的な AccessToken が b1 と b2 の情報を提供します；
分析
AからCのステップで、3者の相互承認と信頼関係が完成しました；
ステップDとEは、タイムアウトが終了するまでの期間、サービスプロバイダに情報b1とb2を提供するためのもので、ステップAからCを再度実行する必要はありません；
すべてのステップを分析することで、プロセス全体にとって最も重要な情報が提供され、最終的に三者関係が保証されます；
考えてみると、認可機関が信頼できるサービス・プロバイダーにしか認可を与えないようにするにはどうすればいいのでしょうか？
例としてgithubのauthプロセスを続けます。
ステップ A では、client_id という重要なパラメータがあります。
ドキュメントからわかるように、client_idは、サービスプロバイダが第三者認証機関にアプリケーションを登録する際に、第三者認証機関からサービスプロバイダに発行される一意のIDです。
ステップDに進みます。
ステップAよりも重要なパラメータが1つあります：client_secretです。
client_idまたはclient_secretのどちらかは、サービス提供者がgithubにアプリケーションを登録する際にgithubから発行されるclient_idです。
client_idとclient_secretは、サービスプロバイダがステップAとDで認証機関と正当なサービスプロバイダ間の信頼ブリッジを確保するのに役立ちます。
なぜclient_idがあるのにclient_secretが必要なのでしょうか？
この質問は、安全・安心の領域に関わるものです。
まず、ステップAでは、認可機関にc2情報を通知するためにclient_idを渡すだけでよいのに対して、ステップDでは、認可機関が取得したc2情報を信頼するためにclient_idとclient_secretの両方を一緒に渡す必要があることがわかります。
よく見ると、ステップAのリクエストはサービスプロバイダのクライアントから送信され、ステップDのリクエストはサービスプロバイダのサーバーから送信されています。
ここまでで、OAuth2.0の認証コードモデルの最初のステップは、サービスプロバイダのクライアントによって開始されなければならないことが理解でき、クライアントによって開始されたリクエストは、弱いセキュリティのネットワーク環境に基づいている可能性がありますが、認証機関とサービスプロバイダを関連付けることができる情報の一部を運ぶ必要があります。OAuth2.0は、client_idパラメータがステップAに含まれるように設計しており、client_idが完全に信頼できないことを示しています。
client_idは完全に信頼できないため、ステップCで返された認証コードを保存して、認証機関から関連情報を取得するために使用することはできません。
また、サービスプロバイダのサーバは、認証コードを取得し、サーバにのみ保存されているclient_idおよびclient_secretと組み合わせ、認証機関に別のリクエストを送信してAccessTokenを取得し、安全なネットワーク環境に基づいて認証プロセス全体を完了する必要があります。
概要
OAuth2.0の認証コードスキーマに記述されているステップは、3者認証に必要なすべての情報を提供し、3者がお互いを信頼するための最も基本的で最も必要なステップを提供します。
最後に、純粋に個人的な意見ですが、もし乖離があれば、議論して修正することを歓迎します。
