🚗 👩‍👩‍👧‍👦 👨🏿‍🏫 承認の微妙さ：OAuth2.0テクノロジーの概要 🏴‍☠️ 💧 👶🏼

Dodo IS情報システムは、Tracker、Restaurant Cashier、KnowledgeBaseなどの44の異なるサービスで構成されています。複数のアカウントに気を取られないように、3年前にパススルー認証を実装するAuthサービスを作成しましたが、現在はOAuth2.0認証標準に基づく2番目のバージョンを作成しています。この標準は非常に複雑ですが、多くのサービスを備えた複雑なアーキテクチャがある場合は、独自の認証サービスを開発するときにOAuth2.0が役立ちます。この記事では、標準についてできるだけ簡単かつ明確に説明し、学習時間を節約できるようにしました。

認証タスク

数十のサービスでの承認の問題は、数年前、「モノリスを鋸で切る時代」の初めに発生しました。この問題は、Authと呼ばれる新しいサービスで解決されました。彼は、さまざまなサービス間でシームレスな認証を実装し、ユーザーデータを個別のデータベースに移行するのを支援しました。

Authサービスには3つの主要なタスクがあります。

すべてのシステムサービスの単一認証ポイント（SSO）。サービスは資格情報を保存しませんが、これを1つの専用サービスに信頼します。
リソースへの安全できめ細かいアクセス。パスワードは1つの場所に保存され、可能な限り安全であるため、安全です。サービス所有者は、認証サービスからのデータに基づいて、必要に応じてリソースへのアクセスを構成できるため、きめ細かくなります。
. , , .

Authの最初のバージョンはモノリスの一部です。サービスとの通信に独自のプロトコルを使用します。そのような「計画」はその時点で必要でしたが、数年の作業の後に問題が現れました。

Authはモノリスの一部です。その結果、サービスはリリースサイクルに関連付けられ、独立した開発と展開が不可能になります。さらに、たとえばサービスをスケーリングするときにAuthをデプロイする場合は、モノリス全体をデプロイする必要があります。

DodoISはAuthに依存しています。古い実装では、外部サービスはすべてのユーザーアクションでAuthを呼び出して、それに関するデータを検証します。この緊密なバインドにより、何らかの理由でAuthがスタックした場合、DodoIS全体が機能しなくなる可能性があります。

認証はRedisに依存します..。さらに、それは非常に強力です-Redisの誤動作はAuthの低下につながります。記載されているSLAが99.9％のAzureRedisを使用しています。これは、サービスが1か月あたり最大44分間利用できない可能性があることを意味します。このようなダウンタイムは許容されません。

Authの現在の実装では、標準に依存せずに独自の認証プロトコルを使用しています。ほとんどのサービスでは、C＃を使用しており（バックエンドについて話している場合）、プロトコル用のライブラリを維持することに問題はありません。しかし、Python、Go、またはRustのサービスが突然登場した場合、これらの言語のライブラリの開発とサポートにはさらに時間がかかり、さらに複雑になります。

現在の認証では、役割に基づく役割ベースのアクセス制御スキームを使用しています..。通常、ロールには、特定の機能に関連付けられるのではなく、特定のサービスへのフルアクセスが付与されます。たとえば、ピッツェリアには、スケジュールを作成したり、原材料を考慮したりするなど、特定のプロジェクトを主導できる副マネージャーがいます。ただし、システムの特定のコンポーネントに対する権利の発行はありません。従業員が任意のアカウンティングコンポーネントのスケジュールまたは設定にアクセスできるように、サービスへのフルアクセスを許可する必要があります。

問題が発生したため、新しいバージョンのAuthを設計および作成する必要がありました。プロジェクトの開始時に、OAuth2.0およびOpenIDConnect1.0の認証および認証標準の調査のみを3週間行いました。

注意..。誇張されて、この記事はRFCの再話であり、何が起こっているのかを理解するために何度か読み直さなければなりませんでした。ここでは、この複雑さを回避し、サービスレスポンスに含まれる可能性のある文字など、複雑なことを説明せずに、すべてを単純、構造化、簡潔に伝えようとしました。RFCとは異なり、これを一度読んだ後、すべてを理解することができます。この記事が、認証サービスを実装するためのソリューションを選択する際に役立ち、時間を節約できることを願っています。あるいは、誰かにその必要性について考えさせるかもしれません。

OAuth2.0とは何ですか？

利用可能なプロトコルとテクノロジーを調べて、新しいAuthの開発を開始することにしました。最も一般的な認証標準は、OAuth2.0認証フレームワークです。

この規格は2012年に採用され、8年以上にわたってプロトコルが変更され、補足されてきました。RFCが非常に多いため、元のプロトコルの作成者はOAuth 2.1を作成することを決定しました。これにより、OAuth2.0に対する現在のすべての変更が1つのドキュメントにまとめられます。彼がドラフト段階にある間。

OAuthの現在のバージョンは、RFC6749で説明されています。分析します。

OAuth2.0は認証フレームワークです。

安全な認証を確保するために、サービス間の通信を実装する方法について説明します。ノード間の相互作用の流れなど、多くのニュアンスが十分に詳細に説明されていますが、特定の実装に翻弄されるものもあります。

特徴：

ユーザーのエンティティとアクセスを要求するアプリケーションを分離します。この分離のおかげで、ユーザー権限とは別にアプリケーション権限を管理できます。

特定の権限と有効期間を持つ通常のログインとパスワードの代わりに、ランダムに生成された文字列（トークン）を使用してリソースにアクセスします。
事前に決められた一連の権利ではなく、自分の希望に基づいて、可能な限り正確に権利を発行できます。

機能を詳しく見てみましょう。

役割

OAuth 2.0は、次の4つの役割を定義します。

リソース所有者は、保護されたリソースへのアクセス権を持つエンティティです。エンティティは、エンドユーザーまたはある種のシステムにすることができます。保護されたリソースはHTTPエンドポイントであり、APIエンドポイント、CDN上のファイル、Webサービスなど、何でもかまいません。
リソースサーバー-リソース所有者がアクセスできる保護されたリソースを格納するサーバー。
クライアント。これは、リソースの所有者に代わって、彼の許可を得て、許可を得て、保護されたリソースへのアクセスを要求するアプリケーションです。
承認サーバー-リソース所有者の承認が成功した後、保護されたリソースにアクセスするためにクライアントにトークンを発行するサーバー。

インタラクションの各参加者は、いくつかの役割を組み合わせることができます。たとえば、クライアントは同時にリソース所有者になり、自分のリソースへのアクセスを要求できます。相互作用スキームをさらに検討してみましょう。

重要：クライアントは事前にサービスに登録する必要があります。どうやってするの？

クライアント登録

特定の実装の~~ファンタジーに~~ 応じて、手動またはサービスの検出など、クライアント登録の方法を選択します。ただし、登録中のどの方法でも、クライアントIDの他に、リダイレクトURIとクライアントタイプの2つのパラメーターを指定する必要があります。

リダイレクトURI-承認が成功した後にリソース所有者が送信されるアドレス。承認に加えて、アドレスは、承認を申請したサービスが本人であることを確認するために使用されます。

クライアントタイプ-クライアントとの対話方法を決定するクライアントのタイプ。クライアントのタイプは、承認のために資格情報（トークン）を安全に保存する能力によって決まります。したがって、クライアントには2つのタイプしかありません。

Confidential — , . , web-, backend.
Public — . , , .

OAuth 2.0のトークンは、クライアントに対して透過的ではない文字列です。通常、文字列はランダムに生成されたように見えます。その形式はクライアントにとって重要ではありません。トークンは、保護されたリソース（アクセストークン）や新しいトークン（更新トークン）などにアクセスするためのキーです。

各トークンには独自の有効期間があります。ただし、更新トークンにはさらに多くの情報が必要です。アクセストークンを取得するために使用されます。たとえば、アクセストークンの有効期間が約1時間の場合、更新トークンは1週間そのままにしておくことができます。

更新トークンはオプションであり、機密クライアントでのみ使用できます..。オプションのトークンを使用すると、一部の実装では、アクセストークンの有効期間が非常に長くなり、更新に煩わされないように、更新トークンはまったく使用されません。しかし、これは安全ではありません。アクセストークンが侵害された場合、リセットすることができ、サービスは更新トークンを使用して新しいアクセストークンを受け取ります。更新トークンがない場合は、承認プロセスを再度実行する必要があります。

アクセストークンには特定のアクセス権のセットが割り当てられ、認証中にクライアントに付与されます。OAuth2.0でのアクセス許可がどのように見えるかを見てみましょう。

アクセス権

アクセス権はスコープとしてクライアントに発行されます。スコープは、スペースで区切られた文字列（scope-token）で構成されるパラメーターです。

各スコープトークンは、クライアントに付与された特定の権限を表します。たとえば、スコープトークンdoc_read は、リソースサーバー上のドキュメントへの読み取りアクセスを提供し、employee 会社の従業員のみにアプリケーション機能へのアクセスを提供できます。最終的なスコープは次のようになりますemail doc_read employee。

OAuth 2.0では、スコープトークンを自分で作成し、ニーズに合わせてカスタマイズします。スコープトークン名は、ファンタジーと2つのASCII文字（"および）によってのみ制限され\ます。

クライアント登録の段階で、認証サービス設定で、クライアントにはデフォルトで標準スコープが与えられます。ただし、クライアントは、承認サーバーに標準以外のスコープを要求できます。承認サーバーのポリシーとリソース所有者の選択によっては、結果のスコープが大きく異なる場合があります。将来的には、クライアントが承認された後、リソース所有者はサービスを再承認せずに一部の権限を取得できますが、追加の権限を発行するには、クライアントの再承認が必要になります。

抽象OAuth2.0。アクセストークンを使用したフロー

ロール、トークンのタイプ、およびスコープがどのように見えるかを調べました。サービスへのアクセスを提供するフローを見てみましょう。

以下は、参加者間の相互作用の抽象的な図（またはフロー）です。この図のすべてのステップは、厳密に上から下に実行されます。もっと詳しく分析してみましょう。

クライアントは、必要なリソース所有者にアクセスするための要求を送信します。
リソース所有者はクライアントに承認付与を返します。これにより、リソース所有者のIDと、クライアントがアクセスを要求しているリソースに対する彼の権利が確認されます。フローに応じて、これはトークンまたは資格情報になります。
クライアントは、前の手順で取得した許可付与を許可サーバーに送信し、クライアントからのアクセストークンが保護されたリソースにアクセスすることを期待します。
承認サーバーは、承認付与が有効であることを確認してから、アクセストークンをクライアントに送り返します。
アクセストークンを受信した後、クライアントはリソースサーバーから保護されたリソースを要求します。
リソースサーバーは、アクセストークンが正しいことを確認してから、保護されたリソースへのアクセスを提供します。

クライアントはリソース所有者から承認を受け、それに基づいてリソースへのアクセスが許可されます。簡単だ。このスキームに更新トークンを追加するのは簡単ですか？

抽象OAuth2.0。更新トークンを使用したフロー

この図では、最初と2番目のステップは省略されています。これらは、上記の抽象的なフロー図と同じです。

より詳細なスキーム：

クライアントには、承認サーバーへの承認付与が付属しており、アクセストークンと更新トークンを提供するように求められます。
Authorization server , authorization grant access token refresh token.
Client access token , — invalid token error.
, authorization server refresh token access token .
access token, refresh token, refresh token.

grant?

Grantは、リソースの所有者によるクライアントの正常な承認を表すデータであり、クライアントがアクセストークンを取得するために使用します。

たとえば、どこかでGoogleで認証すると、目の前に通知がポップアップ表示されます。そのようなサービスがあなたまたはあなたのリソースに関するデータにアクセスしたいと言っています（要求されたスコープトークンが表示されます）。この通知を「同意画面」と呼びます。

「OK」をクリックした瞬間に、同じ許可がデータベースに入ります。そのようなユーザーがそのようなサービスへのそのようなアクセスを許可したというデータが記録されます。クライアントは、データベース内のデータに関連付けられている文字列など、ある種の成功した認証識別子を受け取ります。

助成金を取得するには、4 + 1の方法があります-助成金の種類：

Authorization code — confedencial — web-.
Client credentials — confedential , , .
Implicit — public-, redirection URI (, ), authorization code grant PKCE (Proof Key for Code Exchange — , , token , . — RFC 7636).
リソース所有者のパスワード資格情報。でOAuth 2.0のセキュリティRFC 6819、この補助金の種類は信頼できないと考えられます。以前はOAuth2.0へのサービスの移行にのみ使用が許可されていましたが、現時点ではまったく使用できません。
デバイス認証（RFC 8628で追加）-Webブラウザを備えていない可能性があるが、インターネット経由で動作できるデバイスを認証するために使用されます。たとえば、これらはコンソールアプリケーション、スマートデバイス、またはスマートTVです。

関連すると見なすことができるのは、認証コード（PKCEを使用）、クライアント資格情報、およびデバイス認証付与のみですが、すべてを考慮します。理解が複雑になる順に助成金を検討します。

Client credentials grant flow

フローは最も単純で、あらゆるサービスの定期的な承認を彷彿とさせます。これは、クライアントIDとクライアントシークレットであるクライアントの資格情報を使用して実行されます。これは、ユーザーのログインとパスワードに類似しています。認証には適切に保存する必要のあるクライアントシークレットが必要なため、このフローは機密クライアントのみが使用できます。

スキームは単純です。クライアントは、クライアントIDとクライアントシークレットを渡すことにより、認証サーバーで認証されます。それに応じて、アクセストークンを受け取ります。このトークンを使用して、必要なサービスにすでにアクセスできます。

このフローは、クライアントが自身のリソースまたは認証サーバーと以前に合意したリソースにアクセスしようとするときに必要です。たとえば、サービスAはサービスBに時々アクセスし、ネットワーク内のピッツェリアの数に関するデータを更新する必要があります。

リソース所有者のパスワード資格情報フロー

このRFCで説明されている現在のセキュリティの推奨事項によると、明らかなセキュリティ上の懸念があるため、このフローの使用はまったく推奨されていません。

このフローの図では、2つのクライアントがあり、理論的には、クライアントと承認サーバーが必要です。

リソース所有者は、たとえばクライアントのフォームを介して、ユーザー名とパスワードをクライアントに転送します。次に、クライアントはそれを使用してアクセストークン（およびオプションで更新トークン）を取得します。

ここに問題があります。リソースの所有者は、ユーザー名とパスワードを取得してクライアントに明確な形式で提供するだけですが、これは安全ではありません。もともとは、信頼できるクライアントまたはオペレーティングシステムの一部であるクライアント専用に作成されました。その後、ログインおよびパスワード認証からOAuth2.0への移行のみが許可されました。現在の安全ガイドラインはその使用を禁止しています。

承認コード

現時点で最も一般的なフロー。主に機密クライアントに使用されますが、PKCEによる追加の検証の導入により、パブリッククライアントにも使用できます。

このフローでは、クライアントはユーザーエージェント（ブラウザ）を介してリソース所有者と対話します。 user-agentには1つの要件があります。それは、HTTPリダイレクトを処理できる必要があるということです。これがないと、リソース所有者は認証サーバーにアクセスして、許可を得て戻ることができません。

このフローは前のフローよりも複雑なので、段階的に分析します。まず、私たちがリソースの所有者であり、学習結果をクラウドに保存したいオンライン学習サービスのページに移動したと想像してみましょう。彼は私たちのリソース、たとえばクラウド内の特定のディレクトリにアクセスする必要があります。「ログイン」をクリックすると、承認コード付与フローの旅が始まります。

最初のステップでは、クライアントはuser-agentを使用してリソース所有者をAuthorizationserver認証ページにリダイレクトします。URIでは、クライアントIDとリダイレクトURIを指定します。リダイレクションURIは、承認が成功した後にリソース所有者を返す場所を理解するために使用されます（リソース所有者は、クライアントによって要求されたスコープに許可を付与します）。
user-agent, resource owner .
Resource owner , consent screen .
Resource owner user-agent URI, redirection URI. query- authorization code — , , resource owner .
authorization code , access token ( refresh token, ).
authorization code, , access token ( refresh token). .

リソース所有者の代わりに私たちを想像すると、承認サーバーへのリダイレクトが表示され、認証され、[同意]画面へのアクセスが確認され、すでに実行されているサービスに送信されます。たとえば、Google、Facebook、またはAppleのアカウントでサービスにアクセスすると、これを何度も経験します。

次のフローはこれに基づいています。

暗黙の付与

これは、リダイレクトURIの操作方法を知っているパブリッククライアント向けの承認コード付与フローの最適化です。たとえば、JavaScriptブラウザアプリケーションやモバイルアプリケーションの場合です。クライアントとリソース所有者が対話するユーザーエージェントの要件は変わりません。彼はHTTPリダイレクトを処理できる必要があります。

承認コードと暗黙の主な違いがあります。承認コードとアクセストークンを受け取る代わりに、リソース所有者の承認が成功するとすぐにアクセストークンを受け取ります。さらに、セキュリティ上の理由から、ここではクライアントシークレットは使用されていません。アプリケーションを逆アセンブルして取得できます。信頼性は、リダイレクトURIによってのみチェックされます。

この図の多くのステップは、認証コードのステップと似ていますが、それらについても詳細に分析することを提案します。ブラウザアプリケーションがその設定をGitリポジトリに保存したいとします。「LogintoGitHub」をクリックすると、この段階で暗黙的なフローが始まります。

クライアントは、user-agentとHTTPリダイレクトを使用して、リソース所有者を認証サーバーにリダイレクトします。リクエストパラメータでは、クライアントを認証してからリソース所有者を返すために必要なクライアントIDとリダイレクトURIを渡します。
リソース所有者は、ユーザーエージェントを介して認証サーバーと通信することによって認証されます。同時に、クライアントIDを持って来たクライアントへの助成金の発行を確認します。
grant ( «allow» consent screen), user-agent resource owner redirection URI. , URI fragment access token (URI fragment — , URI ‘#’).
user-agent. User-agent redirection URI web-, access token . , , , CDN.
Web- web- ( ), redirection URI, , .
User-agent , , web-hosted client resource, access token.
結果のアクセストークンuser-agentは、単にクライアントに転送されます。

これは複雑なフローです。実際のシナリオではほとんど使用されません。しかし、それはまだレガシープロジェクトで見つけることができます。

デバイス認証（RFC 8628）

2012年から2019年にかけて、ログインに不便な多くのスマートデバイスが登場しました。たとえば、リソースを開くたびにテレビで複雑なユーザー名とパスワードを入力するのは不便です。これは、グラフィカルインターフェイスのないサーバーOSなど、一部のデバイスでは不可能です。2019年8月、このフローはそのようなシナリオのためだけに登場しました。

デバイス認証付与フローを使用できるようにするには、デバイスに少なくとも3つの要件があります。

デバイスは、発信HTTPS要求を行うことができる必要があります。
デバイスは、URIとIDをユーザーに表示できる必要があります。
承認された各デバイスはリソース所有者に属します。リソース所有者は、承認を成功させるために、指定されたURIに移動して指定されたコードを入力するために、ブラウザーを備えた別のデバイスを持っている必要があります。

矢印が豊富なため、スキームが複雑に見えるかもしれません。その前に複雑なフローを解析したので、段階的に分析してみましょう。

TVを使用してWebサービスにログインしようとしているとしましょう。「デバイスとしてログイン」ボタンが表示されたら、をクリックします。この時点で、デバイスフローが始まります。

TVは認証サーバーに要求を出し、クライアントIDを与えます。
承認サーバーは、そのようなクライアントが登録されており、適切な付与タイプを持っていることを確認します。
, Authorization server device code, user code verification URI. Device code — , .
user code verification URI — resource owner. Redirection URI , QR- — .
, user code verification URI, .
resource owner. verification URI, user code, , scope . resource owner .
この間ずっと、デバイス（ポイント3）はその成功について認証サーバーをポーリングしました。今回の認証が通過したことを期待して、デバイスはデバイスコードとクライアントIDを使用して認証サーバーに再度アクセスします。
今回は、リソース所有者がデバイスへの必要な権限の転送を確認すると、承認サーバーは要求に応答してアクセストークンを返します（サーバー設定と更新トークンによって提供された場合）。そして、トークンの助けを借りて、デバイスはすでにリソースで動作し続けることができます。

矢印の明らかな複雑さにもかかわらず、このフローも非常に単純です。デバイスを操作する必要がある場合（トラッカー、キャッシュレジスター、ストアフロント、その他のデバイスなど、多くのデバイスがあります）、このフローを使用する必要があります。

出力の代わりに

この記事では、最も重要なことを最も簡単でアクセスしやすい方法で説明するために、多くの詳細を省略しました。たとえば、クエリの種類、パラメータを渡す方法と形式、その値として許可される文字などです。

このトピックについてさらに詳しく知りたい場合は、RFC 6749（OAuth 2.0の場合）およびRFC 8628（デバイスフローの場合）をお勧めします。OAuthリソースで最新のRFCを確認することもできます。

記事が役に立ち、詳細が必要な場合は、コメントに書き込んでください。次の記事では、PKCE、OpenID Connect 1.0認証プロトコル、認証サーバーの実装などについて説明します。

便利なリンク：

承認の微妙さ：OAuth2.0テクノロジーの概要