OAuthとは何か？簡単に解説

### 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]リソースオーナーに対して許可を要求
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/770055/0777f818-9124-5f7d-4bb3-ef3cd950b4df.png)

まず始めにクライアントはリソースオーナーに対して許可の要求をします。上記図では認可サーバを経由し許可の要求を依頼していますが、直接要求することも可能です。

##### [手順2] リソースオーナーから「認可グラント」を受け取る
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/770055/83575430-d807-6814-ec83-c54c8cf8602d.png)

リソースオーナーに認証が許可されたクライアントは「認可グラント」と呼ばれるリソースオーナーからの認可を現す情報を受け取ります。


##### [手順3] 認可サーバに対してアクセストークンを要求する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/770055/e9c63c0e-9f2f-0dfd-c852-68cc5cd4fd50.png)


リソースオーナーに許可されたクライアントは、認可サーバに対して「認可グラント」を提示し、リソースサーバへのアクセスするために必要な「アクセストークン」を要求します。


##### [手順4] リソースサーバへリソース提供の要求を行う
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/770055/d8c18ede-e348-5c20-657c-cc2951bf0b6c.png)

クライアントは、リソースサーバにリソース提供の要求を行います。この時、認可サーバから発行された「アクセストークン」も一緒に送ります。


##### [手順6] クライアントにリソースを提供する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/770055/513b28c0-71fe-a7cc-2e03-65832aaa568e.png)

リソースサーバは、クライアントから送られてきた「アクセストークン」の正当性を確認し、正当であればクライアントからの要求を受け入れ、リソースを提供します。


### OpenIDとの違い
似た用語で、OpenIDというのもありました。
この仕組みは、Webサービスの増加に伴い、マッシュアップ（複数のWebサービスを連動させて新しいサービスを作ること）が行われるようになってきたことで、ユーザーが複数のサービスに別々にユーザー登録をするわずらわしさを防ぐための仕組みです。

　OpenIDでは、連携して機能する複数のWebサービスのユーザーが同一人物であることはわかりますが、Webサービス間でどのユーザーリソースに対してアクセスできるか、また、どのような操作ができるかという認可を行うものではありません。したがって、共通のユーザーIDを使ってログインしても、操作はあくまでもユーザーが別々に行うことが原則となります。

　一方OAuthでは、認証を与えたサービスの保持しているユーザーリソースを、認証を与えられたサービスが利用することができます。どのような利用が可能か（読み取り専用か、書き換え可能かなど）についても、OAuthの認証の中で明確に記述されています。



OAuth認証について詳しく載っているサイト
https://ritou.hatenablog.com/entry/2020/12/01/000000
 

参考
https://www.youtube.com/channel/UC--TPTOTN0O178CcwvMNV6w