「お金のあるアパートの鍵も持っているのではないでしょうか？」 -このようなことは、外部サービスがメインメールのパスワードを必要とする人の通常の反応のように見えます。 ただし、私たちのほとんどは、定期的にサードパーティのサービスにパスワードを提供する必要があります。 今日は、OAuth 2.0を使用してメールボックスからレターを収集する際の認証手順の実装方法について説明します。これにより、Mail.Ruユーザーは、メールから第三者への「キー」を信頼する必要がなくなります。



通常、メールコレクター、メールクライアント、またはサードパーティのモバイルアプリケーションを設定するときは、名前、メールボックスアドレス、およびパスワードを入力する必要があります。 この手順で最も不快なのは、パスワードの入力です。 セキュリティに関心がある場合は、このメールボックスに特別な複雑なパスワードを考え出し、サービスWebサイトでのみ入力しました。 そして、パスワードを第三者に信頼する必要があります。第三者はそのパスワードを保存し、ネットワーク経由で送信します。 転送がそれほど悪くない場合（Mail.Ru MailはIMAPプロトコルのSSLデータ転送をサポートしています）、パスワードの保存は危険です。 パスワードはどのような形式で保存されますか？ 彼らはそれを盗むことができますか？ 部外者がメールを読むことはできますか？ また、メールにアクセスするのはサードパーティのサービスのみですか？ 彼は、クラウドからファイルを誤って削除しますか？ ユーザーはよく同様の質問をします。



サードパーティのリソースサーバーにパスワードを保存しないようにすることができます。 解決策は明らかです。IMAPを介してMail.Ruから他のメールプロバイダーのメールボックスにメールを収集するとき、およびメールクライアントやサードパーティのモバイルアプリケーションとやり取りするときに、OAuth 2.0を介して作業する機会を全員に提供します。 そして、私たちはこの一歩を踏み出しました。 そして今、まず最初に。

OAuthの概要

一般的なOAuthとは何ですか？ 完全なプロトコル仕様は、 RFC 6749で説明されています 。 複数の認証オプションがあります。 たとえば、モバイルアプリケーションは、Webアプリケーションやデバイスとは少し異なる方法でリソースにアクセスします。 プレゼンテーションを簡単にするために、Webアプリケーションの特定のケースに限定しています。



OAuthにはいくつかの役割があります。



リソース所有者は、アプリケーションが自分に代わってアクションを実行できるようにするユーザーです。



リソースサーバー -リソース所有者が所有するサービスを提供するサーバー（たとえば、リソースサーバーは、ボックスが配置されているメールサーバーにすることができます）。



承認サーバー -OAuthプロバイダーによって承認されたサーバー。 最も単純なケースでは、少なくとも外部の観点からは、承認サーバーとリソースサーバーはまったく同じです。



クライアント -OAuth用語では、これはユーザーからリソースへのアクセスを取得するWebアプリケーションです。 各クライアントは許可サーバーに登録する必要があります。 そうすることで、client_idとclient_secretを受け取ります。 実際、これはOAuthプロバイダーがクライアントアプリケーションを識別するためのユーザー名とパスワードです。 このユーザー名とパスワードのペアは、識別のためにのみ使用され、ユーザーのユーザー名とパスワードと決して一致しないことが重要です。 したがって、ユーザーはどのような状況でもパスワードを第三者に転送しません。許可サーバーとのみこのデータを交換します。メールボックスを入力するのと同じくらい安全です。

仕組み

そのため、特定のサイト（OAuthプロバイダー）のユーザー（リソース所有者）は、自分の代わりに機能の一部を操作する権利を別のサイト（クライアント）に移したいと考えています。 この手順は、OAuth許可付与と呼ばれます。 その実装のために、クライアントはユーザーにOAuthプロバイダーのサーバーにアクセスして、そこにアクセスコードを取得し、以下で説明する特定のパラメーターを渡すように要求します。 技術的には、これは既知のURLへのブラウザーリダイレクトのように見えます。 ユーザーがこのURLをクリックすると、OAuthプロバイダーはユーザーにログインを要求し、このアプリケーションへの要求されたアクセスを許可する必要があるかどうかを尋ねます。 ユーザーが同意すると、OAuthプロバイダーはユーザーのブラウザーをクライアントサーバーにリダイレクトし、そこにアクセスコードを渡します。 その後、クライアントは、クライアントを認証するclient_id、client_secret、およびアクセストークン（access_token）に交換するために受信したコードを使用して、アクセストークンの認証コードを交換するための特別なHTTP要求を生成します。 リクエストはサーバー側から実行されます。 このトークンは、アプリケーションがOAuthプロバイダーAPIを入力するためのパスワードとして機能します。







OAuthパスワードは、パスワードを所有するユーザーと、このパスワードを検証できる唯一のサーバー間でのみ交換されます。 ユーザーは、OAuthプロバイダーのサーバーでのみパスワードを入力します。 クライアントアプリケーションは、client_secretをOAuthプロバイダーにのみ送信します。 同時に、プロバイダーには、このユーザーがこの特定のアプリケーションにまさにこのレベルのアクセス権を付与したことを確認する機会があります。 アプリケーションは、動作するために必要なアクセス権を取得しますが、ユーザーのパスワードを知りません。 ユーザーは自分のパスワードを第三者に転送しないため、パスワードは自分だけに知られていると確信しています。



スコープは、許可付与ステージのパラメーターの1つとして渡されます。 このパラメーターは、アプリケーションが受け取りたい権利を決定します。 パラメーターは、OAuthプロバイダーが理解できるスペースで区切られたシーケンスで構成される文字列です。 ここで注目すべきは、access_tokenによって、クライアントアプリケーションがscopeパラメーターにリストされたアクションのみを実行できるようになることです。 OAuthプロバイダーは、ユーザーがアプリケーションに権利データを転送することに同意することを確認する前に、ユーザーに同じ権限のリストを表示します。



許可付与ステージのもう1つの興味深いパラメーターは状態と呼ばれ、明らかなセキュリティ問題を回避します。 ユーザーをOAuthプロバイダーのサイトにリダイレクトするアプリケーションは、ランダムトークン（CSRFトークン）を生成し、それを状態パラメーターに渡します。 OAuthプロバイダーは何も行いませんが、アクセスコードとともにそれを返します。 アプリケーションは、受信した状態と送信内容を確認し、状態が正しくない場合は許可付与ステージを中止します。 これが発生しなかった場合、潜在的な攻撃者は、アプリケーションがメールボックスにアクセスすることを許可し、許可コードをアプリケーションに転送する可能性があります。



外部アカウントのバインディングが外部メールボックスによる認証に使用されるとしましょう。 この場合、攻撃者はあなたのアカウントにログインして、私たちのアプリケーションで被害者のアカウントにアクセスすることができます。 したがって、このパラメーターはオプションですが、OAuthを実装するすべてのユーザーに状態を使用することをお勧めします。







場合によっては、access_tokenとともに、OAuthプロバイダーはrefresh_tokenをクライアントに発行します。 このトークンを使用すると、新しいaccess_tokenまたは複数のトークンを取得できます。 最も単純な場合、ユーザーはアプリケーションに1回だけ許可を与えます。 たとえば、アプリケーションはユーザーのカレンダーにイベントを追加したいと考えています。 これが発生するたびに、ユーザーはリクエストを受け取ります：合意されたアクションの実行をアプリケーションに許可するかどうか？ 彼が同意すると、access_tokenが短時間（たとえば1時間）発行されます。 明日、アプリケーションが別のイベントを追加しようとすると、ユーザーから再度アクセスが要求されます。 これが、AppleデバイスでのApp Storeの仕組みです。 アプリケーションをインストールするには、パスワードを入力する必要がありますが、他のアプリケーションをインストールするときの次の15分間はこれは必要ありません。 15分後に別のアプリケーションをインストールしようとすると、パスワードを再度入力する必要があります。



場合によっては、ユーザーは常に自分に代わって作業する権利をアプリケーションに与えたいことがあります。 顕著な例は、単なるメールコレクターです。 ユーザーがオンラインになっているか、1か月間アルタイ山脈でハイキングに行ったかに関係なく、コレクターは1つ以上のメールボックスからメールをピックアップする必要があります。 この状況では、refresh_tokenが必要です。 クライアントアプリケーションは、いわゆるオフラインアクセスを要求し、応答でrefresh_tokenを取得できます。これにより、ユーザーの介入なしにOAuthプロバイダーのサービスで承認し、ますます多くのaccess_tokenを受信できます。

方法：クライアント

最近、OAuthを使用したメールコレクターの作業のサポートを追加しました。 これで、ユーザーにメールボックスのパスワードの入力を強制することはなくなり、Mail.Ruのメールボックスからメールを収集することもあり、コレクターはメールサーバーに対してOAuthクライアントとして機能します。 このプロトコルで作業できるようにするサービス、つまりGoogleとMicrosoftのOAuthをサポートしています。 トークンを保存するために、内部Fluorサービスを作成しました。 トークンデータベースの保存に加えて、彼のタスクには、要求に応じてコレクターやその他の国内消費者に最小限の遅延で発行することが含まれます。 別個のデーモンは、承認を担当する外部サービスからのトークンに対するユーザーの同意を交換します。 アプリケーションに必要な権限を発行するプロセスを段階的にガイドし（ステージ許可付与）、受信したトークンをFluorに保存します。



refresh_tokenをサポートし、access_tokenの有効期間を制限するサービスの場合、データベース内のトークンをタイムリーに更新する必要があります。 同時に、1つのアプリケーションまたは1つのIPからの1日あたりのリクエスト数によるOAuthプロバイダーの制限に該当してはなりません。 fluor-refreshデーモンはこのタスクを処理します。 FluorデーモンファミリはPerlで記述されています。 それらへの要求は、AnyEventライブラリを使用して非同期的に処理されます。 独自のIPROTOプロトコルを使用して、OAuthデーモンおよびコレクターと対話します。 Perlには独自のHTTPサーバーもありますが、ヘッダーを解析する必要があるため、IPROTO要求処理のパフォーマンスは5倍高くなっています。 プロセッサの観点から最も重要なタスクは、PerlからXSです。 XSを使用すると、コードの一部をCで記述し、その作業結果をPerlに転送できます。



ある時点で、Fluorとfluor-refreshの複数のコピーを開始できます。 Tarantool（同じくHabréで複数回記述されたオープンソースプロジェクトであるMail.Ruで開発された）を介して、トークンのストレージとデーモン間の相互作用を整理します。 Tarantoolは、サーバーのメモリに完全に配置されたNoSQLデータベースですが、データをディスクに書き込むことができます。 Tarantoolには複製機能があり、Lua言語でかなり複雑な手順を作成できるため、トークンを更新するための特定のキューを整理するのに役立ちます。



キューの詳細は、最初は無限であり（トークンは常に更新する必要があります）、次にキューのタスクは特定の期限、期限までに完了する必要があるということです。 この場合、キュー内の1つのタスクが2つのリフレッシャーによって一度に取得されないようにする必要があります。そうしないと、無駄な作業が行われ、サードパーティサービスへのリクエストの頻度が超過します。 関連するすべてのロジックをLuaに実装しました。



Fluor-refreshは、単にTarantoolの関数を呼び出し、更新用のトークンのリストを取得します。 タスクについては、新しいaccess_tokenを受け取り、別のLua関数を介してTarantoolに保存します。 Lua関数は、1つのトークンの更新が複数のリフレッシャーに委ねられないこと、およびトークンが常に選択され、その有効期限が指定された間隔内に発生することを保証します。 したがって、Tarantoolの代わりに、たとえばmemcachedがあった場合に実行する必要があるいくつかのクエリをデータベースに保存します。



それでもこの電子メールのトークンが更新されておらず、有効期限が切れていない場合、コレクターはFluorに、キューをバイパスして新しいaccess_tokenをすぐに取得するように依頼する場合があります。 ユーザーがOAuthプロバイダーからアプリケーションへのアクセスを取り消す場合もあります。 OAuthプロトコルは、この状況を報告するメカニズムをアプリケーションに提供しません。 refresh_tokenが機能しなくなったときの問題について調べます。 この場合、トークンを削除する必要があり、同時にコレクターはextra_auth状態になります。つまり、ユーザーは再度アクセスを要求する必要があります。



現在、さまざまなサービスの480万トークンがFluorデータベースに格納されており、メモリの7 GBを占めています。 1日に約1億のトークン更新が発生します。 ただし、Fluorは、コレクターからの1日あたり1億2500万件のリクエストを処理します。 物理的には、障害発生時に冗長性を考慮しない場合、1台のサーバーでこれを処理できます。

方法：サーバー

最も単純な場合、OAuthサーバーは次のことができるはずです。

1. 承認を確認する機能を持っている。
2. アクセストークンと更新トークン、および認証コードを生成します。
3. トークンを確認、保存、無効化、削除します。
4. refresh_tokenで、access_tokenを更新し、認証コードで、refresh_tokenとaccess_tokenを発行します。

通常、 承認チェックは別のサービスによって実行されます。 ログイン+パスワードのペア、またはより複雑な組み合わせ（たとえば、2要素認証の場合）に対してユーザーを承認します。 OAuthを作成する場合、すでにこのサービスがあります。



トークン生成。 一般的なアドバイス：トークンはできるだけランダムである必要があり、ランダムは暗号的に強力である必要があります。



トークン管理 各トークンにはライフタイムがあり、ユーザーに関連付けられています。 データベース内の単純なテーブルにより、トークンの保存、ユーザーへのバインド、および有効期間が許可されます。 データが少なく、作業速度が速いため、RAMにデータを保存するデータベースが望ましいです。 また、データベースをバイパスして古いトークンを削除するデーモンも必要です。



リフレッシュトークンによる新しいアクセストークンの発行は 、かなり平凡な手順であり、それに焦点を合わせません。 これにはTarantoolを使用します。 データをメモリに保存し、整合性を確保します。 そして最も重要なことは、古いトークンを削除するロジックをカプセル化します。 これは、内部Luaプロシージャで実装できます。 もう1つの興味深い点は、ユーザーがパスワードを変更した場合にトークンを削除することです。 これを行うには、ユーザーに関連付けられているすべてのトークンを取得する必要があります。 これには、ユーザーに応じて作成されるセカンダリインデックスが必要です。他の多くのデータベースとは異なり、Tarantoolにはこのような機会があります。



システム構成の機能。 ここで重要なのは、速度、鉄の使用率、耐障害性の3点です。 Tarantoolは、RAMおよびセカンダリインデックスとのみ対話することにより、作業の速度を提供します。 鉄の利用については、サーバーのプロセッサコアを最大限に使用できるようにするTarantoolを分割します。 フォールトトレランスは、異なるDCでのレプリケーションによって実現されます。 レプリケーションを使用すると、個々のデーモンとマシン全体の両方を再起動できます。



そのため、本日、OAuth認証を使用してMail.RuメールサービスのIMAPプロトコルに接続する機能を発表しました。 デスクトップおよびモバイルデバイスの開発者とクライアントに、メールボックスからメールを収集するときに実装することをお勧めします。



接続に関するドキュメントは、当社のWebサイトで入手できます。 現時点では、この機会を提供するサービスからメールをより安全な方法で収集し、その数を増やしたいと考えています。 すぐにOAuth 2.0での作業がHTTPSでの作業と同じ電子メールサービスのゴールドスタンダードになることを願っています。