OAuth 2とJWTを使用してマイクロサービスにセキュリティを提供

Part 1-理論関連
作者freewolf
キーワード 、 Spring Cloud 、 OAuth 2.0 、 JWT 、 Spring Security 、 SSO 、 UAA前に書く
10年以上IT業界やプログラムに従事してきたベテランドライバーとして、今日はマイクロサービスが分からないと言ったら、自分のソフトウェアを作るのが耻ずかしいです.SOAは何年も叫んでいて、誰も知らないが、本当のSOAを開発するシステムはどれだけあるのだろうか.しかし、一夜にしてすべての人がマイクロサービスの懐に入ったようだ.
現在最も主流の「マイクロサービスフレームワーク」として、Spring Cloudは急速に発展し、最も包括的なマイクロサービスソリューションとなっている.どんなソフトウェアシステムでも、どんなフレームワークでも、セキュリティは永遠に避けられない話題であり、私も最近のマイクロサービスの研究の冒頭としています.
古い話題!「どのようにしてマイクロサービスシステムで安全を保証することができますか?」という目標を達成するために、Spring Cloudのサービスの安全を保護するために、ここでは簡単で実行可能な方法を採用しています.つまり、統一的なユーザー授権センターを構築します.
ここで補足して、Authentication（ ）とAuthorization（ ）とは何かを言いますが、実は簡単で、認証はあなたが誰なのか、鑑権はあなたが何ができるかに関心を持っています.みんなが一致して言った例を挙げて、もしあなたが空港に行って飛行機に乗ったら、あなたが持っているパスポートはあなたの身分を代表して、これは認証で、あなたの航空券はあなたの権限で、あなたは何ができますか.
マイクロサービスを学ぶのは簡単な探索過程ではなく、DDD(Domain Driven Design)領域駆動設計における領域モデルに従っても、マイクロサービスをより小さな粒度に分割しても、多くの新しい知識を学ぶことはできない.多くの新しい問題と以前からよく解決されていない問題に直面します.絶えず考えるにつれて、Facebook/GitHub/AWSのこれらの機関がどのように内部資源を保護するかを熟知するにつれて、答えも次第に浮上してきた.
この目標を効率的に達成するために、ここではOAuth 2とJWT(JSON Web Tokens)の技術をソリューションとして採用し、
なぜOAuth 2を使うのか
マイクロサービスは現代のソフトウェア開発においてまだ新鮮なものであるが、OAuth 2はすでに広く使用されているライセンス技術であり、Web開発者が自分でサービスを提供する中で、Google/Facebook/GitHubプラットフォームのユーザー情報に安全な方法で直接アクセスできるようにしている.しかし、私が詳細を説明する前に、私は本論文の本当のテーマに焦点を当てます: では、クラウドサービスにおけるユーザーアクセスリソースの制御は、一般的にどのように行われていますか?しかし、私はみんなが使ったようだが、完璧ではない例を挙げます.
すべてのアクセス要求が送信されると仮定して、境界サーバまたは認証機能付き逆プロキシサーバを設定できます.認証に合格したら、内部の対応するサーバに転送します.一般的にSpring MVC Security開発ではほとんどそうします.しかし、これは安全ではありません.最も重要なのは、誰かが内部から攻撃すると、あなたのデータには安全性がありません.
その他の方法:私たちはすべてのサービスのために統一的な権限データベースを構築し、要求するたびにユーザーを認証します.いくつかの面では愚かに聞こえますが、実際には実行可能なセキュリティ案です.
より良い方法:ユーザは、認証サービスによって認証を実現し、ユーザアクセスSessionをTokenにマッピングする.すべてのリモート・アクセス・リソース・サーバに関連するAPIは、Tokenを提供する必要があります.その後、リソースサーバは、認証サービスにアクセスしてTokenを識別し、Tokenがどのユーザに属しているかを知り、このTokenを通じてどのリソースにアクセスできるかを知る.
これはいい案に聞こえますよね?しかし、Tokenの安全な伝送をどのように保証しますか?ユーザー・アクセスと他のサービス・アクセスの区別方法これは私たちが関心を持っている問題に違いない.
したがって、上記の様々な問題は、OAuth 2を使用することを選択しました.実際には、Facebook/Googleの機密データにアクセスすることは、私たち自身のバックエンドの保護されたデータにアクセスすることと何の違いもありません.そして、彼らはこのようなソリューションを何年も使用しています.私たちはこれらの方法に従うだけでいいです.OAuth 2はどのように働いていますか.OAuth 2に関する原理を知っていれば、OAuth 2を導入するのは簡単です.「 AppはTomのFacebookに関するデータを取得することを望んでいる」というシナリオについて説明します.
OAuth 2には、プロセス全体で4つの役割があります.

リソース所有者(ResourceOwner)-Tom

です.

リソースサーバ(ResourceServer)-Facebook

です.

ライセンスサーバ(Authorization Server)-ここではもちろんFacebookです.Facebookには関連データが

あるからです.

クライアント(Client)-App

TomがFacebook Appにログインしようとすると、Facebookのライセンスサーバにリダイレクトし、Tomがログインに成功し、自分のEmailと個人情報が Appによって取得されることを許可する.この2つのリソースは、Scope（ ）として定義され、許可されると、 Appの開発者は、アクセス権範囲で定義された2つのリソースを申請することができる.

+--------+                               +---------------+
|        |--(A)- Authorization Request ->|   Resource    |
|        |                               |     Owner     |
|        || Authorization |
| Client |                               |     Server    |
|        ||    Resource   |
|        |                               |     Server    |
|        |

Tomは、権限要求を許可し、再びリダイレクトによって Appに戻り、リダイレクトに戻ったときにAccess Token（ ）を携帯し、 Appは、Access Tokenに関連する認証を再作成することなく、このFacebookを通じてTomから関連する認証リソース(すなわち、Emailおよび個人情報)を直接取得することができる.また、Tomが Appにログインするたびに、以前に取得したAccess Tokenを介して、関連するライセンスリソースを直接取得することができる.
これまで、上記の内容を実際の例に直接使用するにはどうすればいいですか?OAuth 2は非常に友好的で、導入が容易で、すべてのインタラクションはクライアントと権限の範囲に関するものです.

OAuth 2の と は、私たちの普段のユーザーと権限と同じですか?

権限範囲に権限をマッピングするか、クライアントにユーザーをマッピングする必要がありますか?

なぜクライアントが必要なのですか?

以前、同様のエンタープライズ開発事例で関連するロールをマッピングしようとしたことがあるかもしれません.これは厄介です!
いずれのタイプのアプリケーションもユーザログインを提供し、ログイン結果はAccess Tokenであり、その後のすべてのAPI呼び出しはこのAccess TokenをHTTP要求ヘッダに追加し、呼び出されたサービスはAccess Tokenを認証し、Tokenがアクセス可能な権限情報を取得することをサーバに許可する.これにより、すべてのサービスへのアクセスは、認証を完了するために別のサービスを要求します.
権限範囲と役割、クライアントとユーザーOAuth 2では、どのアプリケーション(Webサイト、モバイルクライアント、デスクトップアプリケーション、その他)がそれらのリソースにアクセスできるかを定義できます.ここには1つのサイズしかありません.どこから来たユーザーがそれらのデータにアクセスできます.もちろん、どのアプリケーションやサービスがそれらのリソースにアクセスできます.言い換えれば、権限範囲は、エンドポイントがクライアントに表示されるか、またはユーザがその権限に基づいて関連するデータを取得するかを制御することである.
1つのオンラインショップでは、フロントエンドは1つのクライアントと見なすことができ、商品、注文、顧客情報にアクセスすることができるが、バックエンドは物流や契約などに関することができる一方、ユーザーは1つのサービスにアクセスすることができるが、すべてのデータではない.これは、ユーザーがWebアプリケーションを使用しているためであり、彼ができない場合、他のユーザーは可能である.サービス間のアクセス時に議論する別の次元.数学に詳しい場合は、OAuth 2でクライアント-権限範囲関係はユーザー-権限関係とは線形に独立していると言えます.
なぜJWTなのかOAuth 2は、Access Tokenをどこに探してどこに存在するかに関心を持たず、ランダム文字列を生成し、Tokenに関連するデータを保存してこれらの文字列に保存します.1つのトークンエンドポイントを介して、他のサービスは、このTokenが有効であるかどうか、どの権限を通過できるかに関心を持つ可能性があります.これがユーザ情報を取得するためにサーバをリソースサーバに変換するユーザ情報URLメソッドである.
マイクロサービスについてお話しすると、複雑なタスクであるにもかかわらず、ライセンスサーバが水平に拡張されることを保証するために、Tokenストレージを探す必要があります.すべてのマイクロサービスリソースへのアクセス要求はHttp HeaderにTokenを携帯しており、アクセスされたサービスは次にライセンスサーバにTokenの有効性の検証を要求します.現在、この方法では、2回以上の要求が必要ですが、セキュリティのためには他の方法はありません.しかし、Tokenストレージの拡張は、JWT（ jot）を導入した理由で、システムの拡張性に大きな影響を及ぼします.

+-----------+                                     +-------------+
|           |       1-Request Authorization       |             |
|           |------------------------------------>|             |
|           |     grant_type&username&password    |             |--+
|           |                                     |Authorization|  | 2-Gen
|  Client   |                                     |Service      |  |   JWT
|           |       3-Response Authorization      |             |

簡単に言えば、1人のユーザ要求に応答するとき、ユーザ情報と許可範囲をシーケンス化してJSON文字列を入れ、Base 64を用いて符号化し、最終的に許可サーバで でこの文字列に署名し、JSON Web Tokenを得、Access Tokenを用いるように直接使用することができる.他のすべてのリソースサーバがRSA公開鍵を持っていると仮定します.Http HeaderにTokenが格納されているこの要求をリソースサーバが受信すると、リソースサーバはこのTokenを取得し、正しい秘密鍵署名(認証サーバ署名、すなわち )が使用されているかどうかを検証することができる. が通過し、逆シーケンス化されるとOAuth 2の検証情報が得られる.
認証サーバが返す情報は次のとおりです.

access_token-リソースアクセス

用アクセストークン

refresh_token-アクセストークンが無効になった場合、このトークンを使用してアクセストークン

を再取得する

token_type-トークンタイプ、ここではBearer、すなわち基本HTTP認証

である.

expire_in-有効期限

jti - JWT ID

Access TokenはBase64 であるため、逆符号化後は以下のフォーマット、標準的なJWTフォーマットである.つまりHeader、Payload、Signatureの3つの部分です.

{ 
  "alg":"RS256",
  "typ":"JWT"
}
{
  "exp": 1492873315,
  "user_name": "reader",
  "authorities": [
    "AURH_READ"
  ],
  "jti": "8f2d40eb-0d75-44df-a8cc-8c37320e3548",
  "client_id": "web_app",
  "scope": [
    "FOO"
  ]
}
&:lƧs)ۡ-[+
F"2"Kآ8ۓٞ:u9ٴ̯ޡ 9Q32Zƌ޿$ec{3mxJh0DF [!뀭N) knVVĖV| ׄE㍫}Ŝf9>'

JWTを使用すると、Tokenを簡単に伝送することができ、RSA でTokenが偽造されにくいことを保証することができる.Access Token文字列にはユーザー情報と権限範囲が含まれており、私たちが必要とするすべての情報があるので、Tokenのストレージを維持する必要はありません.リソースサーバもTokenのチェックを要求する必要はありません.

+-----------+                                    +-----------+
|           |       1-Request Resource           |           |
|           |----------------------------------->|           |
|           | Authorization: bearer Access Token |           |--+
|           |                                    | Resource  |  | 2-Verify
|  Client   |                                    | Service   |  |  Token
|           |       3-Response Resource          |           |

したがって、OAuth 2は、マイクロサービスにおいて使用され、全体的なアーキテクチャの拡張性に影響を及ぼさない.特に、Access Tokenが期限切れになった後、Refresh Tokenを使用して認証サーバにAccess Tokenを再取得するなど、具体的な例が後述する.
興味があれば、あとで実現部分もありますので、お楽しみに~
によってhttp://asciiflow.com/フローチャートは中国語では揃えられませんが、本文のフローチャートはすべて英語です~