仕事でOAuthについて勉強する機会があったので、その際に学んだメモです。
実際の身近なサービスをイメージすると理解しやすかったです。

OAuthとは

Open Authorizationの略。
SNSやWebサービス間でHTTP上で「アクセス権限の認可」を行うためのプロトコルのこと。
たとえば、InstagramとFacebookに同じ写真を投稿する場合、通常であれば、InstagramとFacebookの両方に、ログインIDとパスワードを入力して、ログインが必要になるはず。
しかし、実際はInstagramへのログインだけでどちらにも投稿が可能となっています。
この共有機能に使われているのがOAuthプロトコルなのです。

つまり、

※OAuth2は「認証」する仕組みではなく、「認可」する仕組みです。
（どのサイトでも強調されていた...）

認証と認可の違い

認証：「誰が」通信相手かを確認する
認可：「誰が」「誰に」「何の権限を」出来る？を確認する

OAuthを利用するメリット

パスワードをサードパーティのアプリに渡すことなくAPIを利用できる
どのリソースにアクセス可能かを細かくユーザーに認可させることができる
ユーザーがパスワードを変更してもアクセストークンに影響がない
ID/パスワードが漏洩したとしても、影響がない

OAuthにはOAuth 1.0 と OAuth 2.0　がある

OAuth 1.0 と OAuth 2.0 の仕組みについてはこちらの記事に
👉🏻https://murashun.jp/blog/20150920-01.html#chapter-3

OAuth1.0の問題点やOAuth2.0の特徴についてはこちらの記事に
👉🏻http://www.atmarkit.co.jp/fsmart/articles/oauth2/01.html

OAuthのクライアントタイプ

OAuthは2種類のクライアントタイプがある
• コンフィデンシャルクライアント (Confidential Client)
サーバ上で動くWebアプリなどのように、client_secretを秘密にできるクライアント。Confidential Clientはクライアント登録時にclient_idとclient_secretという情報を受け取る。

• パブリッククライアント (Public Client)
JSアプリやスマホ上のネイティブアプリなどのように、client_secretを秘密にできないクライアント。Public Clientはクライアント登録時にclient_idのみを受け取る。

OAuth2.0の発行フロー

OAuth2.0には4種類のフローがある

•  Authorization Code Grant（認可コードグラント）
•  Implicit Grant（インプリシットグラント）
•  Resource Owner Password Credentials Grant（リソースオーナーパスワードクレデンシャルグラント）
•  Client Credentials Grant（クライアントクレデンシャルグラント）

The OAuth 2.0 Authorization Frameworkより
・・・
ちょっとよくわからないので、発行フローのシーケンス図が読めるようになろう...😥

認証の流れ

どのサービスがクライアント（サービスを使う側）、
そのサービスがサーバー（サービスを提供する側）に当たるのか意識すると理解しやすいと思います。
今回の例だと、
Facebookがサーバー（サービスを提供する側）
Instagramがクライアント（サービスを使う側）です。
InstagramがFacebookのOAuth機能を使って、Facebookに写真を投稿したい、という流れです。

登場人物（ロール）

Section 1.1 Rolesより

名前	役割	具体例
Resource Owner（リソースオーナー）	リソースへのアクセス権限を許可する人またはエンティティ	ブラウザ
Resource Server（リソースサーバー）	Access Tokenを使ったリソースへのリクエストを受理してリソースを提供することのできるサーバー	FacebookのAPIサーバー
Client（クライアント）	権限に基づき、Resource Ownerの代理としてリソースを要求するアプリケーション（Webアプリでも、PC/モバイルアプリでも）	ユーザーが使っているアプリやサービス
Authorization Server（認可サーバー）	リソースオーナーが認可し権限付与した後、Clientに対し、Access Tokenを発行するサーバー	Facebookの認証サーバー