#OAuth2とは？
OAuth2は、ユーザーが自分のデータにアクセスしたり自分に代わって別のWebサービス（OAuthプロバイダー）で何かを実行したりするためにWebサービスまたはアプリケーションに許可を付与するプロセスを合理化するための仕組みです。 4つの異なるOAuth2フローがあり、あなたのニーズに最も合うものを理解するためには、こちらの記事（英語）を参照してください。この記事では、エンジニア、プロジェクトマネージャ、および投資家が、OAuth2フロー図を通じて、各OAuth２フロータイプの流れを一目で理解できるようにする簡単な紹介になります。
前回公開したQiita記事では、４つのOAuth2グラントタイプをセキュリティー、実装の難しさ、活用度の３つの観点から比べて説明しました。この記事では、４つ並べてやり取りの仕組みを比べまました。そして、各OAuth2タイプに置いて（ユーザー、ウエブブラウザー/ネイティブAPP、ウエブサービス、OAuthプロバイダー）の間でのデーターのやり取りをわかりやすく比べています。
#全てのOAuth2フローでの共通する事柄
全てのOAuth2フローは、同じ目的をゴールにしています。
- ユーザーから一連の権限を委譲された事を表す認証キー/アクセストークンを取得し、ユーザーに代わって何かを実行する。
上記のゴールを達成する為に、２つの方法があります。
- アクセストークンの取得
- ユーザの認証キー/アクセストークンをOAuthプロバイダ（例：Twitter）から取得します。
- アクセストークンを使用する
- 承認キー/アクセストークンを使用して、ユーザーに代わり保護されたAPIエンドポイントを呼び出すことで何かを実行します（ツイートを投稿するなど）。
#全てのOAuth2フローでの異なる事柄
全てのOAuth2付与タイプフローは、メインフローの最初の部分だけが異なります。
- アクセストークンの取得方法が違います。
原則として、アクセストークン取得フローには5つのステップがあります（下の図を参照）。
- クライアントID/クライアントシークレットを取得するために、OAuthサーバーにクライアント（アプリ）を事前登録する。
- OAuthサーバーは、ユーザーがクライアントIDで、紐付けされたアプリのソーシャルログインボタンをクリックしたときに、ユーザーを認証します。
- OAuthサーバーは、アプリがユーザーに代わって、何かを実行できるようにするためにユーザーの許可を求めます。
- OAuthサーバーはシークレットコードをアプリに送信します。
- アプリは、シークレットコードとクライアントシークレットを提示することによって、OAuthサーバーから認証キー/アクセストークンを取得します。
OAuthフロー図解
注釈：
- 雲のアイコンは、アプリ
- wwwアイコンは、ユーザー/ブラウザ
- 金庫のアイコンは、OAuthプロバイダー
- ”ー”は「該当なし」を意味します。つまりそのステップは必要ありません。
##認可コードタイプ(Authorization Code Grant Type)
認証コード（左から3番目）のグラントタイプフローが5つのステップすべてを含み、そして、キー/アクセストークンはApp（バックエンド）に対してのみ発行されるため最も安全であることが簡単にわかります。これは十分に保護されているため（ステップ＃5）、システムの攻撃される対象が少ないです。
##インプリシットタイプ(Implicit Code Grant Type)
インプリシットタイプフロー（右端）は、ステップ＃4が必要ありません。つまりOAuthサーバーがキー/アクセストークンをユーザーブラウザに直接返すことを除いて、認証コードタイプと最も似ています。これにより、キー/アクセストークンがブラウザに保存されるため、システムの攻撃される対象が多いです。なぜなら、App（バックエンド）よりもインターネットに晒されています。更新出来ない、有効期限が短いプロビジョニングキー/アクセストークンによってリスクを軽減出来ます。
インプリシットタイプは、シングルページアプリ（SPA）やネイティブモバイルアプリなど、アプリにバックエンドがない場合に有効です。
##クライアント・クレデェンシャルタイプ(Client Credential Grant Type Flow)
クライアント・クレデェンシャルタイプのフロー（一番左）は簡単で、2つのステップしかありません。
しかし、ユーザーがアプリと同じ主体であることを要求します。なぜなら、ステップ＃5でOAuthサーバーと通信するとき、ユーザーは自分自身を識別するためにアプリのクライアントID /クライアントシークレットを使用するからです。したがって、このグラントタイプの使用例は限られていますが、キー/アクセストークンがApp（バックエンド）に渡されるので安全です。
##リソースオーナー・パスワード・クレデンシャルタイプ(Resource Owner Password Credential Grant Type Flow)
リソース所有者パスワード資格付与タイプのフローも2つのステップだけで簡単ですが、ステップ＃2でユーザーはアプリにユーザー名/パスワードを渡す必要があります。 アプリとOAuthサーバーが同じエンティティに属していない限り、アプリにユーザー名/パスワードを渡すと、ユーザーとしてすべての権限を持つアプリに権限が与えられます。これはセキュリティリスクです。
##まとめ
４つのOAuth2タイプは、アクセストークンの取得とアクセストークンの使用フローの2つの仕組みで構成されています。 後者はすべてのOAuth2タイプで同じですが、前者はタイプによって異なります。一般的に5つのステップに分割することができ、差は、各ステップに関与する主体から生じます。
OAuthを実装する際の複雑さに対処したくない場合、OAuthをWebサービスとして簡単に利用したい場合、プラットフォームとしてOAuthプロバイダになる場合、またはシングルサインオン（SSO）用のOAuthを使用する場合は、OAuth.ioの専門担当へインターコム、メールからご連絡をお願いします。お手伝いいたします（日本語対応可）！
または、こちらからデモの予約を受けたまります。