投稿者：Vyacheslav Mikhailov、ソリューションアーキテクト



これは、昨年の夏に読んだレポートに基づいた入門書です。 印刷物は、次のような詳細情報を提案します 1つのレポートでは、通常、すべての詳細について話すことはできません。



ユーザー認証プロセス、シングルサインオン/ SSOテクノロジーの操作を扱い、特定の技術的な実装を掘り下げることなく、OAuth2テクノロジーとその仕組みの概要を説明します。 次の記事では、実装の成功例として、Thinktecture Identity Server v3ライブラリーについて検討し、その機能について詳しく説明し、マイクロサービスアーキテクチャでの作業に必要であり、戦闘システムでの使用にふさわしいコンポーネントの最小セットを組み立てる方法について説明します。 第3部では、システムのニーズに合わせてこのライブラリを拡張し、多くの開発者の人生で遭遇するさまざまなシナリオを各ケースの推奨事項とともに分析することにより、一連の記事を完成させる方法を示します。

認証とは何ですか？

認証と承認のプロセスは、アクセス権の分離に基づいており、これなしでは多かれ少なかれ深刻なアプリケーションは実行できません。 したがって、それらが以前どのように発生し、現在どのように発生しているかを理解することは非常に重要ですが、テクノロジーの説明を掘り下げる前に、重要な用語を見てみましょう。



識別とは、目の前にどんな人がいるかを判断するプロセスです。 認証は、この人物が本人であることを正確に確認するプロセスです。 認可とは、この認証された人物に何を許可するかを決定するプロセスです。 つまり、これらは3つの異なる一貫した概念であり、相互に交換できない概念です。 多くの場合、認証の一部として識別が暗示されます。 最も重要なことは、認証と承認を明確に区別することです。



認証中に、私たちに来た人が身元の証拠を持っていることを確認します。 この記事では主に認証に焦点を当てます。

認証方法

HTTPプロトコルを使用する場合、最も単純な認証方法は基本アクセス認証です。 原則として、このプロトコルは時代遅れであり、特に保護されていない接続でインターネットで使用されることはほとんどありませんが、それらの一部がずっと前に作成されたという理由だけで企業システムに保存されます。 仕組みを理解する価値があります。

HTTP基本認証

保護されたリソースにアクセスすると、サーバーはアクセス権のないユーザーを発行するという最初の問題は、401 Unauthorizedエラーになります。 応答には、受け入れることができる認証の種類（この場合はBasic）、およびこの認証が有効なコンテキスト（領域）に関する情報も含まれています。 ユーザーがユーザー名とパスワードを入力すると、それらはBase64にパッケージ化され、検証のためにサーバーに送信されます。 ここにはさまざまな危険があります。 最も一般的なのは、中間者攻撃または中間攻撃の脅威です。その間、安全でない接続を使用して、攻撃者はクライアントからサーバーへ、またはサーバーへの転送時に資格情報を傍受できます。

HTTPダイジェスト認証

技術開発の次のステップは、わずかに複雑なHTTPダイジェスト認証システムでした。これにより、明確な資格情報が不要になります。ここでは、検証にいくつかの不純物を含むMD5ハッシュが使用され、ログインとパスワードの選択が回避されます。 もちろん、このアルゴリズムはより信頼性が高いように見えますが、それほど複雑ではない攻撃も多く発生します。 たとえば、 ここでは攻撃についてさらに詳しく読むことができます。

フォーム認証

その後、フォーム認証プロセスが登場しました。このプロセスでは、抽象化モデルのより高いレベルで認証が行われます。 HTTPサーバーはアクセスエラーを報告せず、認証されていないユーザーを別のページにリダイレクトするだけです。 通常、このページにはログインとパスワードを入力するためのフィールドが表示されます。入力後、 POST要求がデータで生成され、安全なチャネルを通じてサーバーに送信されます。 サーバー側は、ユーザーにトークンまたはセッション識別子を返します。トークンまたはセッション識別子は、Cookieに保存され、保護されたリソースへのアクセスに使用されます。

トークン認証

次世代の認証方法は、トークンベースの認証です。これは、シングルサインオン（SSO）システムの構築で一般的に使用されます。 使用する場合、要求されたサービスは、ユーザー情報を検証する機能を別のサービスに委任します。 つまり、サービスプロバイダーは、トークンプロバイダー自体（IDプロバイダー）へのアクセスに必要なトークンの発行を信頼します。 これは、たとえば、ソーシャルネットワークのアカウントを介してアプリケーションを入力する場合に見られるものです。 IT以外では、このプロセスの最も単純な例えは、共通のパスポートの使用です。 公式文書はあなたに発行された単なるトークンです-すべての公共サービスは、デフォルトで、それを渡した警察署を信頼し、その完全性を維持しながら、有効期間を通して認証にパスポートを十分と見なします。



この図は、トークン認証を使用する場合にアプリケーションが情報を交換する方法と順序を明確に示しています。







次の図は、ユーザーが直接関与する相互作用の段階をさらに反映しています。 この点は、このようなスキームの欠点です。リソースへのアクセスを取得するには、常にユーザーが必要です。

OAuth2とOpen ID Connect

認証トークンは保護されたリソースにアクセスする瞬間にユーザーの存在を必要とするため、プロセスのさらなる改善が必要でした。 なぜなら、IDプロバイダーは、コントロールを制御に転送するときに、ユーザーと対話して、たとえばログインとパスワードを要求するからです。



たとえば、ソーシャルネットワークの連絡先リストにアクセスするために、ユーザーに代わって一定の間隔で特定の3番目のリソースに問い合わせる必要があるサービスの場合、トークン認証は機能しなくなります。 実際には、セッション識別子は通常非常に長くは生きないため、傍受された場合、攻撃者は限られた時間だけサービスにアクセスできます。 ただし、有効期間が短いため、たとえば夜間のプロセスではトークンは十分ではありません。



2006年、TwitterのOpen IDプロトコルの実装に取り​​組んでいる間に、新しいオープン認証プロトコルの必要性が浮上しました。 2007年にGoogleとAOLのエンジニアが協力し始め、2009年にTwitterはユーザーに、OAuthプロトコルに基づいてサードパーティサービスへのアカウントへのアクセスを委任するソリューションを提供しました。 3年後、新しいバージョン-OAuth 2が公開されました。これにより、クライアントアプリケーションの開発が簡素化され、ユーザーの介入なしでトークンを更新するなど、多くの新機能が提供されました。 多くのサービスは、公式に承認される前にこのプロトコルの使用を開始しました。

xyからxyを詳細に理解します

現在、次のプロトコルが審理中です。

1. OpenID-ユーザー資格情報（識別と認証）を検証します。
2. OAuthとは、何かにアクセスすることです。
3. OpenID Connect-両方について。

3つのプロトコルはすべて、ユーザーが自分の秘密のユーザー名とパスワードを信頼できないアプリケーションに開示しないようにします。 OpenIDとOAuthは2014年まで並行して開発され、最終的にOpenID Connectに統合されました。



OpenID 1.0 （2006）およびOpenID 2.0 （2007）では、アプリケーション（arb）が信頼できるサーバー（権限）からのユーザーチェックを要求できました。 バージョン間の違いは重要ではありません。

• ユーザー->アプリ：こんにちは、Mishaです。
• アプリ->権限：これは「この」ミーシャですか？
• 権限とユーザーは対面で通信します。
• Authority-> App：はい、これはMishaです。

OpenID Attribute Exchange 1.0 （2007）は、ユーザープロファイルを取得および保存できるようにすることでOpenID 2.0を拡張します。

• ユーザー->アプリ：こんにちは、Mishaです。
• アプリ->権限：これは「この」ミーシャですか？ これがミーシャの場合、彼にメールを送ってください。
• 権限とユーザーは対面で通信します。
• Authority-> App：はい、これはMishaです。 そして彼のメールはxxx@xxx.xxxです。
  
  

OAuth 1.0 （2010）を使用すると、ユーザーは、認証機関を信頼するサードパーティサーバー（サードパーティサーバー）でアプリケーションに制限付きアクセスを許可できます。

• アプリ->ユーザー：別のサーバーから写真を受け取りたい。
• 権限とユーザーは対面で通信します。
• 機関->アプリ：ここには15分間のチケット（アクセストークン）があります。
• アプリ->サードパーティサーバー：ここでは、チケットでこのユーザーの写真を取得できます。

OAuth 2.0 （2012）はOAuth 1.0と同じですが、プロトコルのみが大幅に変更され、よりシンプルになりました。



OpenID Connect （2014）は、OpenID 2.0、OpenID Attribute Exchange 1.0、およびOAuth 2.0の機能を1つの共通プロトコルに結合します。 アプリケーションは、認証機関を使用して次のことができます。

• ユーザー資格情報を確認してください。
• ユーザープロファイル（またはその一部）を受け取ります。

OpenID Connectは外部リソースへのアクセスを提供しないことを理解することが重要です。 OAuth 2.0を使用して、プロファイルパラメータをそのようなリソースであるかのように提示します。

平面図

通常、システムにはさまざまなコンポーネントがあります。ブラウザを介して作業するユーザー、モバイルアプリケーションを介してサーバーと対話するユーザー、およびWeb APIを介してアクセスされる他のサーバーに保存されたデータを必要とするサーバーアプリケーションのみです。



シングルサインオン-シングルサインオンテクノロジー-ユーザーは、再認証なしで異なるアプリケーションを切り替えることができます。 SSOを使用すると、複数のログインを回避できるため、ユーザーはこれらのスイッチに気付かないだけです。 この場合、インフラストラクチャ内にこのようなアプリケーションが複数存在する状況は常に満たされています。 シングルサインオンテクノロジは、疎結合された多数のアプリケーションで構成される大規模なエンタープライズシステムで特に便利です。 ユーザーがタイムトラッキングシステム、企業フォーラム、またはドキュメントの内部データベースにアクセスするたびにユーザー名とパスワードを入力しても満足されることはほとんどありません。



実装として、OAuth2プロトコルを検討します。 原則として、Windowsと正常にやり取りするKerberosなどの他のものがありますが、Windows、Mac、およびUNIXシステムの両方を使用するコンピューターがある異種ネットワークの場合、独自のプロトコルを使用することはしばしば不便です。 さらに、これはサービスへのアクセスがWeb経由で実行される場合に適用されます-ここではOAuth2が最適な候補です。







上の図は、各タイプの対話に使用されるプロトコルを示しています。

「 xyからxyを詳細に理解している 」セクションからわかるように、ユーザーからユーザー資格情報を取得して確認するには、OpenID Connectが必要です。 OAuth 2.0は、アクセストークンを受け取り、それらにアクセスするために必要です。

OAuth2およびOpenID Connectの用語

• OpenID Connectプロバイダー（OP）
• クライアント
• ユーザー
• 範囲
  
  
  • IDスコープ-OpenID、プロファイル、メール
  • リソーススコープ-さまざまなAPI
  
  
  
• 認証/トークンリクエスト
• 識別トークン
• アクセストークン
• 更新トークン

トークン発行サービス

Open ID Connectプロバイダーは、中央集中型認証サービスの設計全体で最も重要なオブジェクトです。セキュリティトークンサービス、IDプロバイダー認証サーバーなどとも呼ばれます。さまざまなソースが異なる方法で呼び出しますが、クライアントにトークンを発行するサービスです。



主な機能：

• 内部ユーザーストレージまたは外部ソース（Active Directoryなど）を使用してユーザーを認証します。
• クライアント（ストア）を管理し、認証します。
• セッション管理とシングルサインオンを実装する機能を提供します。
• IDトークンとアクセストークンをクライアントに発行します。
• 以前に発行されたトークンを確認してください。

お客様

クライアント-ユーザー認証用のトークンまたは特定のリソースへのアクセス用のトークンのいずれかを必要とするデバイスまたはプログラム（ブラウザー、アプリケーション）（このリソースは、クライアントがトークンを要求する特定の「 セキュリティトークンサービス 」に「馴染みがある」ことが理解されるアクセス用）。

ユーザー

ユーザー-実際にはエンドユーザーは人です。

範囲

スコープ-クライアントがアクセスしたいリソースの識別子。 スコープリストは、認証要求の一部としてトークン発行サービスに送信されます 。



デフォルトでは、すべてのクライアントは任意のエリアを要求することができますが、これはトークン発行サービスの構成で制限することができます（および制限する必要があります） 。



スコープには2つの形式があります。

1. IDスコープは、ユーザー情報の要求です。 彼の名前、プロフィール、性別、写真、メールアドレスなど
2. リソーススコープは、クライアントがアクセスしたい外部リソース（Web API）の名前です。

認証リクエスト

認証/トークン要求-認証要求プロセス。



要求されたスコープに応じて、トークン発行サービスは以下を返します。

1. IDスコープのみが要求される場合は、IDトークンのみ。
2. リソーススコープも要求される場合は、IDトークンとアクセストークン。
3. オフラインアクセスが要求された場合、アクセストークンとリフレッシュトークン。

認証プロセスの詳細については、「認証プロセス 」セクションをご覧ください。

パーソナリティトークン

IDトークン-認証確認。 このトークンには、ユーザー情報の最小限のセットが含まれています。

アクセストークン

アクセストークン-特定のユーザーに許可されている情報。 クライアントはアクセストークンを要求し、それを使用してリソース（Web API）にアクセスします。 アクセストークンには、クライアントとユーザーに関する情報が含まれます（存在する場合）。 ユーザーがプロセスに直接関与していないような種類の承認があることを理解することが重要です（これについては次のパートで詳しく説明します）

トークンを更新

更新トークン-STSが新しいアクセストークンを返すためのトークン。 動作モードに応じて、リフレッシュトークンは再利用可能および使い捨て可能です。 ワンタイムトークンの場合、新しいアクセストークンを要求すると、既製のリフレッシュトークンも生成されます。これは、更新時に使用する必要があります。 明らかに、ワンタイムトークンはより安全です。



セクション「 トークン構造 」のトークンの構成に関する詳細。

認証プロセス

ユーザーがクライアントにアクセスすると、ユーザーはOpen ID Connectプロバイダーにリダイレクトされ、ユーザーにユーザー名とパスワードが要求されます。 認証検証が成功した場合、ユーザーが保護されたリソースにアクセスできるIDトークンとアクセストークンを返します。

トークン構造

書式

OAuth2実装では、3つの部分で構成されるいわゆるjwtトークンを使用します。 IDプロバイダーに連絡すると、ログイン/パスワードを送信し、その代わりにトークンを受信するとします。 ヘッダー（タイトル）、ペイロード（コンテンツ）、および署名（署名）が含まれます。 jwt.ioでは、それをデコードし、JSON形式でコンテンツを表示できます。 このサイトには、jwtトークンの形成に関するルールの説明もあります。



交換プロセス中に暗号化されずに送信されるトークンに問題はありません。 最初は、安全なHTTPSチャネルを介して通信が行われ、トークンの再暗号化は冗長であるという前提から進めます。 確認する必要があるのは、クライアント側でトークンが置換または改ざんされていないことだけです。このため、署名を取得してサーバーで検証するだけで十分です。 また、トークンには重要な情報は含まれていません。



IDトークンに加えて、ユーザーに発行されたブランドに関する情報を含むアクセストークンもあります。 アクセストークンの盗難は、リソースへの不正アクセスを提供する可能性があるため、アクセストークンの有効性は非常に短いです。 つまり、攻撃者がこのタイプのトークンを取得できた場合、非常に短い時間でアクセスできるようになります。 新しいアクセストークンを取得するには、通常は安全でない環境では表示されない更新トークンが使用されます。特に、ブラウザアクセスモードではまったく使用されません。 認証プロセス中にクライアントに返される正確なトークンについては、次のパートで理解します。

主な分野

トークンの標準フィールドとその必要性について簡単に説明します。

• iss-証明機関のアドレスまたは名前。
• sub-ユーザーID。 少なくとも認証センター内で一意です。
• aud-トークンが発行されるクライアントの名前。
• exp-トークンの有効期限。
• nbf-使用可能な開始時刻（それ以前）。
• iat-トークン発行時間。
• jti-トークンの一意の識別子（トークンを再度「リリース」できないようにするために必要です）。

前半のまとめ

この記事では、次の記事で実用的なソリューションを作成するために必要な理論的および用語的な基礎を提供しようとしました。



お楽しみに。