OAuthとは何か
アプリの開発でzoomのAPIを取得しようとするときに、この言葉が出てきて、そーいえばよく聞く言葉だなと思い調べ、その内容をいかに簡単にまとめました。
インターネット上で簡単に写真が共有できるオンラインアルバムサービス、YouTubeなどの動画共有サービス、instagramやFacebookなどのSNS、Twitter、ブログなど、ユーザー登録をしてさまざまな情報を発信できるWebサービスがあります。
これら複数のサービスを自身のアプリやシステムで利用する時に、わざわざIDとパスワードを入れ直したりせずに、シームレスに利用できるようにする仕組みが「OAuth」です。
複数のアプリケーションを連動させる便利な仕組み
IT用語辞典によると、
OAuthとは、運営主体の異なる複数のWebサイトやネットサービス、ソフトウェアなどの間で、データや機能へのアクセス権限の認可（authorization）情報を送受信するためのプロトコル（通信規約）の一つ。
とあります。
つまり、通常Webサービスを利用するためは、個別にユーザーIDとパスワードを入力してユーザーを認証する必要があります。例えば、ある利用者が「Aサービス」と「Bサービス」に加入している場合、各サービスのリソース（機能や保管しているデータなど）は利用者本人しか利用することはできません。
しかしOAuthは、この異なるサービス間のリソースへのアクセス権限を付与することができる仕組みであり、利用することで、IDやパスワードを入力することなく、アプリケーション間の連動ができるようなのです。
簡単にいうと、OAuthにより権限の許可を付与することで、本来であれば利用することができない、他サービスのリソースを連携してもらうことができます。これはかなり便利ですよね。
たとえば、あなたがオンラインアルバムサービスに写真を投稿すると、同時にあなたのユーザーアカウントでTwitterに「アルバムサービスに写真を投稿しました」というメッセージといっしょに、写真を投稿したページのURLをツイート（つぶやき）するような仕組みです。
また、ログイン画面においてそのアプリやシステムのIDやパスワードを使う代わりに、twitterやFacebookと連携してそのユーザーでログインする状態を作ることができる仕組みも、OAuthの働きによるものです。
どんな仕組みなのか
現在の最新バージョンであるOAuth 2.0では、次の4種類のロール（役割）が存在します。
| 名称 | 説明 |
|---|---|
| リソースオーナー（resource owner） | 保護されたリソースへのアクセスを許可する役割。*リソースオーナーが人間の場合はエンドユーザーと呼ばれる。 |
| リソースサーバ (resource server) | 保護されたリソースを管理。 アクセストークンを用いた保護されたリソースへのリクエストを受理してレスポンスを返す役割。 |
| クライアント (client) | リソースオーナーの認可を得て、リソースオーナーの代理として保護されたリソースに対するリクエストを行う役割。 |
| 認可サーバ (authorization server) | リソースオーナーの認証とリソースオーナーからの認可取得が成功した後、アクセストークンをクライアントに発行する役割。 |
[手順1]リソースオーナーに対して許可を要求
まず始めにクライアントはリソースオーナーに対して許可の要求をします。上記図では認可サーバを経由し許可の要求を依頼していますが、直接要求することも可能です。
[手順2] リソースオーナーから「認可グラント」を受け取る
リソースオーナーに認証が許可されたクライアントは「認可グラント」と呼ばれるリソースオーナーからの認可を現す情報を受け取ります。
[手順3] 認可サーバに対してアクセストークンを要求する
リソースオーナーに許可されたクライアントは、認可サーバに対して「認可グラント」を提示し、リソースサーバへのアクセスするために必要な「アクセストークン」を要求します。
[手順4] リソースサーバへリソース提供の要求を行う
クライアントは、リソースサーバにリソース提供の要求を行います。この時、認可サーバから発行された「アクセストークン」も一緒に送ります。
[手順6] クライアントにリソースを提供する
リソースサーバは、クライアントから送られてきた「アクセストークン」の正当性を確認し、正当であればクライアントからの要求を受け入れ、リソースを提供します。
OpenIDとの違い
似た用語で、OpenIDというのもありました。
この仕組みは、Webサービスの増加に伴い、マッシュアップ（複数のWebサービスを連動させて新しいサービスを作ること）が行われるようになってきたことで、ユーザーが複数のサービスに別々にユーザー登録をするわずらわしさを防ぐための仕組みです。
OpenIDでは、連携して機能する複数のWebサービスのユーザーが同一人物であることはわかりますが、Webサービス間でどのユーザーリソースに対してアクセスできるか、また、どのような操作ができるかという認可を行うものではありません。したがって、共通のユーザーIDを使ってログインしても、操作はあくまでもユーザーが別々に行うことが原則となります。
一方OAuthでは、認証を与えたサービスの保持しているユーザーリソースを、認証を与えられたサービスが利用することができます。どのような利用が可能か（読み取り専用か、書き換え可能かなど）についても、OAuthの認証の中で明確に記述されています。
OAuth認証について詳しく載っているサイト
https://ritou.hatenablog.com/entry/2020/12/01/000000