ちょっと考えてみた35
もう少し、OAuth2.0について調べてみました。
認可の仕組みであることがわかりました。
認証と認可は組み合わせて使われることがほとんどです。
ではどのようなシステムになっているのでしょうか？
以前はどのWebアプリケーション、Webサービスも、それぞれのID、パスワードで認証を行ってから、それを使用してました。
いつのころからか、GoogleのID、パスワードで、他のWebサービスが使用できるようになってました。
これが、OAuthの仕組みのようです。
これは、ID、パスワードの一括管理ではありません。
Youtubeでかんがえてみましょう。
Youtubeには、すでにGoogle のOAuthが入り込んでます。
私たちエンドユーザーが、Youtubeを使いたいとしますと、Youtubeアプリを開きます。そうすると、まず、Googleアカウントの入力を促されます。入力すると、Googleから認可コードをエンドユーザーが受け取れますが、普通は見たことがないでしょう（Youtubeの『ユーザーID』にそのまま載せているのかもしれません。『ユーザーID』は、設定＞詳細設定で見れます。認可コードはワンタイムパスワードのようなものですぐに使えなくなりますが、一意性を利用して最初にユーザーIDを設定しているのかもしれません。）Youtubeは、このエンドユーザーに届いた認可コードと、YoutubeのクライアントIDを、Googleへ送ると、アクセストークンというものを取得できます。
そのあとは、エンドユーザーがリクエストした際に、このアクセストークンを使用して、Googleが管理するこのユーザーのリソースを利用したり、認可情報をもとに制限をかけつつ、レスポンスとしてYoutubeのコンテンツを提供しているのです。
この例では、youtubeとGoogleが提携しているので、認可コードをもらうまでの仕組みはよくわかりません。
そこを理解するなら、Qiitaというサイトは、GitHubアカウントで入るようですので、下記参照にして理解すればよいでしょう。
