Oauth2.0認証方法（一）

SSO（シングル・サイン・オン）とは複数のサイトを一箇所にユーザ登録情報をまとまるとの方法です、よく大企業のポータルサイトで使われています。ホールティングズ会社のポータルサイトでサインインしてから各関連会社サイトやアプリケーションをログイン認証なしでアクセス可能です。
SSOの実装は従来クッキーでユーザIDと認証データを保存されて、繰り返して使われる方法とセッションでユーザIDと認証情報を保存して、認証を行う方法、二つがあります。
クッキー認証方法はあまり安全性が低くて、ドメイン間のアクセスは難しい（間接な方法がありますが）、あまりおすすめされていません。
一方、セッション管理方法では認証サーバを構築して、関連企業サイトとアプリケーションは事前にホワイトリストに登録する方法で対応しています。

**Oauth２．０**方法は最近よく使わています。グループ企業より中小企業間でも簡単に連携できるやSNSより発行されているトークンを使って認証を実施することができるとのメリットがあるため、また、ウェブサイト、リッチクライアント、スマホアプリなど同様に適用でき、幅広く使われています。

下記シーケンス図は一般的なOauth認証を表しています。


![oauth01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/527047/716f5f67-f130-5720-3300-9ff03d921a43.png)

Oauth2.0は下記四つのロールを定義されています。
**- Resource Owner(リソース・オーナー）**
Google,Twitterなどのユーザアカウント
**- Resource Server（リソース・サーバ）**
Google、Twitter,Facebookなど、また自分で立ちあがったサーバ
**- Client application（クライアント・アプリケーション）**
アプリケーション、ウェブサイトのブラウザ側やリッチクライアント、ネーティブアプリ
**- Authorization Server（認証サーバ）**
認証サーバ、リソースサーバと同一サーバ可能

![oauth02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/527047/3b495855-78de-5e26-e58f-c37f005f11a7.png)

クライアントは２種類と定義されています。
・プライバシー型：
クライアント側がPWDを保管しています。ウェブアプリ、クライアントIDおよびPWDはサーバに保管されて、アクセス権限は限られています。
・パブリック型：
クライアント側がPWD保管しません。スマホアプリやリッチクライアントアプリは保存しない、ハッカーされやすいため、その代わりにパブリック型を使います。

***ウェブアプリケーション***
ウェブサイトなど、アプリケーションはウェブサーバより支配されて、認証用のクライアントIDとクライアントPWDはサーバに保存されています。（プライバシークライアント）
![oauth03.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/527047/51f3f47d-cad2-95a4-52bf-0d8b0539af6b.png)

***User Agent Application(リッチウェブクライアント）***
JSより構築されているアプリケーション、ブラウザよりアプリケーションをサーバからローカルにダウンロードしていました。
![oauth04.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/527047/dcd295f6-55e7-8530-0075-668ce7479430.png)


***ネーティブアプリ***
![oauth05.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/527047/7c860965-9fa2-21ff-20a3-361be4170d3d.png)

***Hibrid***
上記のひとつを選んで適用します。

**Oauth　４つの認証方法**

事前にクライアントアプリは認証サーバに登録しておきます、Client ID, Client secret(PWD)は生成されます。
登録時RedirectURIをサーバに提出します、このURIは今後ユーザが認証サーバで認証してから再度アプリにアクセス時のURLです。

四つの認証方法：
・Authorization Code
・Implicit
・Resource Owner Password Credentials
・Client Credentials

***Authorization Code***
１、ユーザよりクライアントアプリをアクセスする
２、認証サーバに登録
３、AuthorizationCodeは発行され、また事前登録されRedirectURIが送られる。
４、RedirectURIにアクセスする、AuthCodeとClientID,PWD一緒には認証サーバに送られ、
５、アクセストークンは発行される
６、アクセストークンによってリソースサーバをアクセス、リソースをアプリへ送る
７、アプリ連携

![oauth06.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/527047/284e4d91-6a15-c485-62e7-327a22e6aad2.png)

***Implicit***
![oauth07.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/527047/7cbeed7e-9599-9650-b384-4058d37e5164.png)

アクセストークンより直接にアプリケーションをアクセスします。
またIDとPWDはローカルに保存され、安全性はあまり高くない。

***Resource Owner Password Credentials***
ユーザより第三方認証用アプリのユーザ名とPWDを入力することを要請します。


実はアクセストークンだけではなく、リフレッシュトークンは連携でアクセスを強化しています。
<img width="653" alt="スクリーンショット 2019-11-03 22.08.54.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/527047/73d14dc1-a8ce-6857-877c-5b60f77dcb6f.png">



参照：
http://tutorials.jenkov.com/oauth2/index.html
https://www.cnblogs.com/cjsblog/p/9174797.html
その他参照先：
https://medium.com/@darutk/diagrams-and-movies-of-all-the-oauth-2-0-flows-194f3c3ade85
https://qiita.com/TakahikoKawasaki/items/200951e5b5929f840a1f