OAuth 2.0とは何ですか？
OAuth（Open Authorization）は、ユーザーがサードパーティのモバイルアプリケーションにユーザー名とパスワードを提供したり、すべてのデータを共有したりすることなく、サードパーティのモバイルアプリケーションが別のサービスプロバイダーに保存されている情報にアクセスすることを許可できるオープンスタンダードです。 、OAuth2.0はOAuth1.0と互換性がありません。
簡単に言えば、これは承認メカニズムです。データ所有者（リソース所有者）は、サードパーティアプリケーション（サードパーティアプリケーション）がこれらのデータを取得するためにシステム（サーバー）に入るのを許可することに同意することをシステムに通知します。したがって、システムは、サードパーティアプリケーションで使用するためのパスワードの代わりに使用される短期エントリトークン（トークン）を生成します。
従来のクライアント-サーバー認証モデルでは、クライアントはサーバーへの認証証明書を使用して、サーバーから保護されたリソースを要求します。
これらのリソースにアクセスするためのサードパーティアプリケーションを提供するには、リソースはユーザー名やパスワードなどの認証情報をサードパーティと共有する必要があります。これにはいくつかの問題と制限があります。
oサードパーティのアプリケーションは、将来使用するためにリソース所有者の資格情報を、通常はパスワードのクリアテキストで保存する必要があります。
oサーバーは、パスワード検証に固有のセキュリティ上の弱点をサポートする必要があります。
oサードパーティのアプリケーションは、リソースへの広範なアクセスを取得します。したがって、リソース所有者には、
制限された期間や、制限されたサブセットにアクセスする機能がありません。
oリソース所有者は、単一のサードパーティへのアクセスを取り消すことはできません。これを行う必要がある場合は、サードパーティのパスワードを変更する必要があります。これは、許可されたすべてのサードパーティに影響します。
OAuthは、認証レイヤーを導入することでこれらの問題を解決します。
OAuthでは、クライアントがリソース所有者によって制御されたリソースへのアクセスを要求し、リソースサーバーによって管理され、リソースとは異なる資格情報のセットが発行されます。アクセストークンが発行されます。これは、認証サーバーによってサードパーティクライアントに発行されます。リソース所有者によって承認されました。クライアントはアクセストークン（文字列を表す文字列：特定のスコープ、有効期間、その他のアクセス属性など）を取得し、それを使用して、リソースサーバーによってホストされている保護されたリソースにアクセスします。
OAuth2には4つのドメインモデル（ロール、ロール）があります。
リソース所有者：リソース所有者は、上記のWeChatユーザーです。
リソースサーバー：リソースサーバーは、前述のWeChatサーバーであり、WeChatユーザーの基本情報をサードパーティアプリケーションに提供します。
クライアント：サードパーティアプリケーションクライアントは、あなたの会社が上記で開発しているサードパーティアプリケーションです。
承認サーバー：承認サーバーの役割は、残りの3つの間の関係を管理する中間層として理解できます。
OAuht2の問題解決の鍵は、承認サーバーを使用してサードパーティアプリケーションにアクセス資格情報を提供することです。これにより、サードパーティアプリケーションは、リソースサーバー上のリソース所有者のアカウントとパスワードを知らなくてもリソースを取得できます。リソースサーバー上の所有者の保護されたリソース。保護されたリソースは、WeChatユーザーの名前とプロフィール写真です。
OAuth2.0の問題シナリオ
OAuthが適用できる場所を理解するために、架空の例を挙げましょう。
Googleに保存されているユーザーの写真を印刷できる「クラウド印刷」ウェブサイトがあります。このサービスを利用するには、ユーザーは「クラウド印刷」にGoogleに保存されている写真の読み取りを許可する必要があります。
クラウド印刷
問題は、ユーザーの許可がある場合にのみ、Googleが「クラウド印刷」でこれらの写真を読み取ることを許可することです。
では、「ユンチョンイン」はどのようにしてユーザー認証を取得するのでしょうか。
従来の方法では、ユーザーは「Cloud Chongyin」にGoogleのユーザー名とパスワードを伝え、後者はユーザーの写真を読むことができます。このアプローチには、次のような重大な欠点があります。
（1）「CloudPrint」は、後続のサービスのためにユーザーのパスワードを保存しますが、これは非常に安全ではありません。
（2）Googleはパスワードログインを展開する必要があり、単純なパスワードログインは安全ではないことがわかっています。
（3）「CloudChongyin」は、ユーザーがGoogleに保存したすべてのデータを取得する権利を有し、ユーザーは「CloudChongyin」認証の範囲と有効期間を制限することはできません。
（4）パスワードを変更することによってのみ、ユーザーは「クラウド印刷」に付与された権限を取り消すことができます。ただし、そうすると、ユーザーが承認した他のすべてのサードパーティアプリケーションが無効になります。
（5）サードパーティのアプリケーションがクラックされている限り、ユーザーパスワードが漏洩し、パスワードで保護されたすべてのデータが漏洩します。
OAuthは、これらの問題を解決するために生まれました。
問題解決のアイデア
コンピューターのすべての問題は、中間層を追加することで解決できます。
OAuthは、「クライアント」と「サービスプロバイダー」の間に認証レイヤーを設定します。「クライアント」は「サービスプロバイダー」に直接ログインすることはできませんが、ユーザーとクライアントを区別するために認証レイヤーにのみログインできます。「クライアント」が認証レイヤーにログインするために使用するトークンは、ユーザーのパスワードとは異なります。ユーザーは、ログイン時に認証レイヤートークンのスコープと有効期間を指定できます。
「クライアント」が認証レイヤーにログインした後、「サービスプロバイダー」は、トークンの範囲と有効性に応じて、ユーザーが保存した情報を「クライアント」に開きます。
用語集
OAuth 2.0を詳細に説明する前に、いくつかの特定の用語を理解する必要があります。以下の説明、特にいくつかの写真を理解するために不可欠です。
（1）サードパーティアプリケーション：この記事では「クライアント」とも呼ばれるサードパーティアプリケーション、つまり前のセクションの例では「クラウド印刷」。
（2）HTTPサービス：この記事では「サービスプロバイダー」と呼ばれるHTTPサービスプロバイダー、つまり前のセクションの例ではGoogleです。
（3）リソース所有者：リソース所有者。この記事では「ユーザー」とも呼ばれます。
（4）ユーザーエージェント：ユーザーエージェント。この記事では、ブラウザーを指します。
（5）認証サーバー：認証サーバー。サービスプロバイダーが認証を処理するために特別に使用するサーバーです。
（6）リソースサーバー：リソースサーバー、つまり、サービスプロバイダーがユーザーが生成したリソースを格納するサーバー。それと認証サーバーは、同じサーバーでも異なるサーバーでもかまいません。
上記の用語を知っていると、OAuthの役割は、「クライアント」が「ユーザー」の許可を安全かつ制御可能に取得し、「サービスプロバイダー」と対話できるようにすることであることを理解するのは難しくありません。
OAuth 2.0プロトコル操作プロセス（プロトコルフロー）
OAuth 2.0の操作フローを下図に示します。これは、RFC6749から取得したものです。（http://www.rfcreader.com/#rfc6749）
図1に示されている抽象的なOAuth2.0フロー
は、4つの役割間の相互作用を説明しており、次の手順が含まれています。
（A）クライアントがリソース所有者に承認を要求します。承認要求は、リソース所有者に直接（図のように）行うことも、できれば仲介として承認サーバーを介して間接的に行うこともできます。
（B）クライアントは、リソース所有者の承認を表す資格情報である承認許可を受け取ります。これは、この仕様で定義されている4つの許可タイプのいずれかまたは拡張許可タイプを使用して表されます。許可付与タイプは、クライアントが許可を要求するために使用する方法と、許可サーバーがサポートするタイプによって異なります。承認付与は、クライアントがアクセストークンを取得するために使用する（保護されたリソースにアクセスするための）リソース所有者の承認を表す資格情報です。この仕様では、4つの付与タイプ（認証コード、暗黙的、リソース所有者のパスワード資格情報、およびクライアント資格情報）と、追加のタイプを定義するための拡張メカニズムを定義しています。
（C）クライアントは、許可サーバーで認証し、許可許可を提示することにより、アクセストークンを要求します。
（D）承認サーバーはクライアントを認証し、承認付与を検証し、有効な場合はアクセストークンを発行します。
（E）クライアントは、保護されたリソースをリソースサーバーに要求し、アクセストークンを提示して認証します。
（F）リソースサーバーはアクセストークンを検証し、有効な場合はリクエストを処理します。
説明例
サードパーティアプリケーションの承認ログイン：APPまたはWebページが一部のサードパーティアプリケーションにアクセスする場合、ユーザーはQQ、Weibo、WeChat承認ログインなどの別の協調プラットフォームにログインする必要があります。
ネイティブアプリ認証：アプリログインリクエストのバックグラウンドインターフェイス。セキュリティ認証のために、すべてのリクエストにトークン情報が含まれます。ログイン確認の場合は、バックグラウンドデータがリクエストされます。
フロントエンドとバックエンドの分離単一ページアプリケーション（spa）：フロントエンドとバックエンドの分離フレームワーク。フロントエンドはバックエンドデータを要求し、vue、react、h5を使用して開発されたアプリなどのoauth2セキュリティ認証を必要とします。
クライアント認証モード
アクセストークンを取得するには、クライアントがユーザーによって認証されている必要があります（認証付与）。OAuth 2.0は、次の4つの認証方法を定義しています。
承認コードモード（承認コード）
簡易モード（暗黙）
パスワードモード（リソース所有者パスワード資格情報）
クライアントモード（クライアント資格情報）
4つの承認モード
承認コードモード
承認コードモデルは、最も完全な機能と最も厳密なプロセスを備えた承認モデルです。
（1）ユーザーがクライアントにアクセスすると、後者は前者を認証サーバーに転送します。ユーザーが承認されていると仮定すると、認証サーバーはユーザーをクライアントが事前に指定した「リダイレクトURI」に転送し、承認コードを添付します。
（2）クライアントは認証コードを受け取り、前の「リダイレクトURI」を添付して、認証サーバーからトークンを申請します：GET / oauth / token？response_type = code＆client_id = test＆redirect_uri = redirect pagelink。リクエストが成功すると、コード認証コードが返されます。通常の有効時間は10分です。
（3）認証サーバーは、認証コードとリダイレクトURIをチェックし、それらが正しいことを確認した後、アクセストークンとリフレッシュトークンをクライアントに送信します。POST / oauth / token？response_type = authorization_code＆code = SplxlOBeZQQYbYS6WxSbIA＆redirect_uri =ページリンクをリダイレクトします。リクエストは、アクセストークンと更新トークンを正常に返します。
上記の手順に必要なパラメータは次のとおりです。
ステップAで、クライアントが認証に適用するURIには、次のパラメーターが含まれます。
response_type：承認タイプ、必須オプションを示します。ここでの値は「コード」として固定されています
client_id：クライアントのID、必須オプションを示します
redirect_uri：リダイレクトURIを示します（オプション）
スコープ：適用される権限のスコープを示します、オプション
state：クライアントの現在の状態を表します。任意の値を指定でき、認証サーバーはこの値をそのまま返します。
以下に例を示します。
GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com
ステップCで、サーバーは次のパラメーターを含むクライアントのURIに応答します。
code：必須オプションである認証コードを示します。このコードの有効期間は非常に短く、通常は10分に設定する必要があります。クライアントはこのコードを一度しか使用できません。そうでない場合、認証サーバーによって拒否されます。このコードは、クライアントIDおよびリダイレクトURIと1対1で対応しています。
状態：クライアント要求にこのパラメーターが含まれている場合、認証サーバーの応答にもこのパラメーターが正確に含まれている必要があります。
以下に例を示します。
HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA&state=xyz
ステップDでは、クライアントが認証サーバーにトークンを申請するためのHTTP要求には、次のパラメーターが含まれます。
grant_type：使用される認証モード、必須オプションを示します。ここでの値は「authorization_code」として固定されています。
code：前のステップで取得した認証コードを示します。必須のオプションです。
redirect_uri：リダイレクトURI、必須オプションを示し、ステップAのパラメーター値と一致している必要があります。
client_id：必須オプションであるクライアントIDを示します。
以下に例を示します。
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
ステップEでは、認証サーバーによって送信されるHTTP応答に次のパラメーターが含まれます。
access_token：必須オプションであるアクセストークンを示します。
token_type：トークンのタイプを示します。この値は大文字と小文字を区別しません。必須オプションです。bearerまたはmacの場合があります。
expires_in：有効期限を秒単位で示します。このパラメーターを省略する場合、有効期限は他の方法で設定する必要があります。
refresh_token：次のアクセストークンを取得するために使用される更新トークンを示します（オプション）。
scope：権限の範囲を示します。クライアントによって適用される範囲と一致している場合、この項目は省略できます。
以下に例を示します。
HTTP/1.1 200 OK Content-Type: application/json;charset=UTF-8 Cache-Control: no-store Pragma: no-cache { "access_token":"2YotnFZFEjr1zCsicMWpAA", "token_type":"example", "expires_in":3600, "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA", "example_parameter":"example_value" }
上記のコードからわかるように、関連するパラメーターはJSON形式（Content-Type：application / json）で送信されます。さらに、HTTPヘッダー情報は、キャッシュしてはならないことを明確に指定しています。
参照
https://oauth.net/2/
OAuth 2.0認証フレームワーク：
http ：//www.rfcreader.com/#rfc6749
https://tools.ietf.org/html/rfc6749
http://www.ruanyifeng.com /blog/2014/05/oauth_2_0.html
https://developers.google.com/identity/protocols/oauth2
Kotlin開発者コミュニティ
Java、Kotlin、Spring / Spring Boot、MySQL、redis、neo4j、NoSQL、Android、JavaScript、React、Node、機能プログラミング、プログラミングアイデア、「高可用性、高性能、高リアルタイム」の大規模分散システムアーキテクチャ設計の共有に重点を置くテーマ。
高可用性、高性能、高リアルタイムの大規模分散システムアーキテクチャ設計。
分散フレームワーク：Zookeeper、分散ミドルウェアフレームワークなど。
分散ストレージ：GridFS、FastDFS、TFS、MemCache、redisおよびその他の
分散データベース：Cobar、tddl、Amoeba、Mycat
クラウドコンピューティング、ビッグデータ、AIアルゴリズム
仮想化、クラウドネイティブテクノロジー
分散コンピューティングフレームワーク：MapReduce、Hadoop、Storm、Flinkおよびその他の
分散通信メカニズム：Dubbo、RPC呼び出し、共有リモートデータ、メッセージキューおよびその他の
メッセージキューMQ：Kafka、MetaQ、RocketMQ
高可用性システムの構築方法：ハードウェアとソフトウェアに基づくミドルウェアやシステムアーキテクチャなどのいくつかの典型的なソリューションの実現：HAProxy、Corosync + Pacemakerベースの高可用性クラスタースイートミドルウェアシステム
Mycatアーキテクチャは
ビッグデータの背後にある進化の問題を分散しました参加：データ、ネットワーク、メモリ、コンピューティング機能の矛盾と調整
Java分散システムの高性能の問題：AIO、NIO、Netty、または自己開発のフレームワーク？
高性能イベントディスパッチメカニズム：スレッドプールモデル、ディスラプターモデルなど。。。
抱きしめる木は工場の終わりに生まれます。9階建てのプラットフォームは地下から始まります。千マイルの旅は1つのステップから始まります。歩数を積み上げないと千マイルに到達できず、小川を積み上げないと川になれません。
Kotlinの紹介
Kotlinは非研究言語であり、非常に実用的な産業グレードのプログラミング言語です。その使命は、プログラマーが実際のエンジニアリングの実践で問題を解決するのを支援することです。Kotlinを使用すると、Javaプログラマーの生活が向上します。Javaのnullポインターエラー、時間を浪費する長い定型コード、冗長な構文制限などはすべてKotlinで消えます。Kotlinはシンプルで実用的で、簡潔で強力な構文、安全で表現力豊か、そして非常に生産的です。
Javaは1995年に生まれ、23年の歴史があります。現在の最新バージョンはJava9です。JVMエコシステムの継続的な開発と繁栄の過程で、Scala、Groovy、Clojureなどの兄弟言語も生まれました。
Kotlinは、JVMファミリーの優れたメンバーでもあります。Kotlinは最新の言語です（バージョン1.0は2016年2月にリリースされました）。その本来の目的は、ScalaなどのJava言語の欠陥を最適化し、よりシンプルで実用的なプログラミング言語機能を提供し、コンパイル時間などのパフォーマンスの問題を解決することです。JetBrainsはこれらの分野で素晴らしい仕事をしてきました。
コトリン言語の特徴
長年Javaで開発した後、何か新しいことを試すことができるのは素晴らしいことです。Java開発者の場合、Kotlinは非常に自然でスムーズです。Swift開発者であれば、Nullabilityなどの使い慣れたものになります。Kotlin言語の機能は次のとおりです。
1.簡潔
ボイラープレートコードの量を大幅に削減します。
2. Javaとの100％の相互運用性
KotlinはJavaクラスと直接対話でき、その逆も可能です。この機能により、コードベースを直接再利用してKotlinに移行できます。Javaの相互運用性はほとんどどこにでもあるからです。Kotlinの強力な最新言語機能をすべて楽しんで使用しながら、プラットフォームAPIと既存のコードベースに直接アクセスできます。
3.拡張機能
Kotlinは、クラスから継承したり、任意のタイプのデザインパターン（デコレータパターンなど）を使用したりすることなく、既存のクラスに新しい機能拡張を提供する機能を提供するという点で、C＃やGosuに似ています。
4.機能プログラミング
Kotlin言語は、Scalaと同様に、最初に機能プログラミングをサポートします。高次関数やラムダ式などの機能的な基本機能を備えています。
5.デフォルトおよび名前付きパラメーター
Kotlinでは、関数内のパラメーターのデフォルト値を設定し、各パラメーターに名前を付けることができます。これは、読みやすいコードを書くのに役立ちます。
6.強力な開発ツールのサポート
また、JetBrainsによって作成されているため、IDEを強力にサポートしています。JavaからKotlinへの自動変換は100％OKではありませんが、確かに非常に優れたツールです。IDEAのツールを使用してJavaコードをKotlinコードに変換すると、結果のコードの60％〜70％を簡単に再利用でき、変更のコストは小さくなります。
シンプルで強力な構文機能に加えて、Kotlinには非常に実用的なAPIとその周りに構築されたエコシステムもあります。例：コレクションAPI、IO拡張、リフレクションAPIなど。同時に、Kotlinコミュニティは、オンラインREPLだけでなく、豊富なドキュメントと多くの学習資料も提供しています。
開発者を幸せにする最新のプログラミング言語。永遠にオープンソース
「エントリーから高度な戦闘までのコトリン」からの写真（Chen Guangjian、Tsinghua University Press）
「エントリーから高度な戦闘までのコトリン」からの写真（Chen Guangjian、Tsinghua University Press）
https://kotlinlang.org/