OAuthの中身を図解してみた
APIを使う時によく目にするのかOAuthです。 私もサイトを作ってAPIを触るときによくお世話になっています。正直なところ、なんとなくで使えてしまうので、OAuthの中身をあまり理解していませんでした。
そんな私に刺さったのが「雰囲気で使わずにきちんと理解する」 と言うタイトルの文言でした。 この本に出会えたことをきっかけに改めてOAuthの中身を勉強しました。 ここでは、図解を使いながらOAuthの中身を整理したいと思います。
なぜOAuthが必要なのか
OAuthはAPIを使うときによく用いられていますがそもそもなぜこれが必要なのでしょうか。OAuthが果たす主な役割としては「リソースの持ち主に許可を取る」「認証と認可を切り分ける」の2つがあります。
・リソースの持ち主に許可を取る
APIで提供したいリソースが一般に公開することができるような場合OAuthを使う必要はありません。 例えば、天気の情報を提供するAPIを用意する場合に、 特定のURLから天気の情報のJSONファイルを取得できれば十分でしょう。
一方でユーザがコンテンツを生成するサービスの場合、リソースの所有者はユーザなのでサービス側が勝手に別のサービスにリソースを提供するのは問題があります。 このような場合、リソースの持ち主であるユーザに、他のサービスにリソースを提供して良いかの許可を取る必要があります。OAuthでは、このリソースの持ち主に許可を取ると言う機能を提供します。
・認証と認可を切り分ける
リソースの持ち主に許可を取る場合に、持ち主本人であることをどのように確認するかが問題となります。
単純な方法としては、連携しようとしている外部のサービス（アプリ）に、認証に必要な情報（IDやパスワード）を共有すれば、 そのアプリが代理でリソースにアクセスできます。 ところがこの場合、外部サービスに平文のパスワードのコピーが置かれてしまったり、またアプリに本人と同じ権限、つまり必要以上の権限を与えてしまうなど様々な問題が生じます。
そこで重要になる考え方が認証と認可を分けると言うことです。OAuthでは トークンによるリソースへのアクセスによってこの認証と認可の分離を行っています。
認証とはリソースの所有者が本人であるかを確認する処理を表します。OAuth では認可サーバーがユーザと直接通信することで、ID,パスワード等を用いた認証を行います。 そして認証されたユーザは認可サーバーに対してアプリへのリソース提供の許可を与えます。
ユーザが許可を与えると認可サーバーはアプリに対してトークンを発行します。 このトークンはリソースへのアクセスの許可証として機能します。 そしてアプリはこのトークンを添えてリソースにアクセスします。 リソースサーバーではトークンを見てそのクライアントがリソースにアクセスする権限を持っているかどうかを確認します。 この権限の確認を認可と呼びます。
こうすることで、アプリにユーザのIDやパスワードといった印象に必要な情報を渡さずに、リソースへのアクセスの許可を与えることができます。
OAuthの流れ
OAuthの大体の動きは上の図で説明したように、認証と認可を分けてアクセスするというものです。 ただし実際にはもう少し流れが複雑で、 全体の流れを図にすると以下のような形になります。
以下ではまとまりごとに流れを説明します。
・連携開始：1〜2
アプリとサービスの連携を開始します。 通常は、アプリ上で連携の開始をユーザがボタン操作などで始めます。 するとアプリ側は認可サーバーに対して認可リクエストを投げます。
・認証：3〜5
認可リクエストを受け取った認可サーバーは、認証画面をユーザに提示します。 ユーザは認証画面からIDやパスワード等の情報を入力します。認可サーバーで認証が正しく行われると、 認可コードと呼ばれる一時的なトークンを返します。
・アクセストークンの取得：6〜8
認可コードは、リダイレクトによってアプリ側に送信されます。 アプリはこの認可コードを添えてアクセストークンのリクエストを認可サーバに送ります。 認可サーバーでは認可コードを検証し、アプリにアクセストークンを返します。
・リソースの取得：9〜10
アクセストークンを受け取ったアプリは、リソースサーバーに対してリソースリクエストをアクセストークン付きで送ります。 リソースサーバではアクセストークンを検証してリソースをアプリに返します。
まとめ
AOuthの中身を図解を含めながらまとめました。なんとなくで使えてしまうのは便利で良いことですが、中身をわかっていた方が気持ちいいですね。
この記事が気に入ったらサポートをしてみませんか？