Abstruct

OAuth2.0について学んだことをまとめておきます。

1. Introduction

  • 定義

    • 「OAuth2.0はサードパーティアプリケーションによるHTTPサービスへの限定的なアクセスを可能にする認可フレームワークである。」
    • 言い換えると
      • 「OAuth2.0は「画像編集アプリによるGoogle Photoへの限定的なアクセス(Aさんの領域へのアップロードのみ)」を可能にするための「アクセストークンの発行方法のルール」である。」
  • 必要性

    • OAuth2.0によりサードパーティにID/Passwordを提供しなくても済むため。
    • もしID/Passwordを提供すると以下の問題がある。
      • サードパーティに自由にHTTPサービスにアクセスされてしまう。
        • しかしOAuth2.0だったら、「もし悪意のある挙動をしたとしても、ユーザーが許可したアクションしか取れない。」
      • 悪用された場合、ID/Passwordを変更するしかない。
        • しかしOAuth2.0だったら、「サードパーティへのOAuth2.0の設定を変更するだけで済む。」
      • サードパーティアプリが攻撃を受けた際に、サードパーティアプリからID/Passwordが漏洩する可能性がある。
        • しかしOAuth2.0だったら、「サードパーティアプリはID/Passwordを保持していないので、漏洩の心配がない。」

2. OAuth roles

  • リソースオーナー
    • リソースの所有者であるため、あらゆる操作が可能。
    • サードパーティにアクセス権限を移譲することも可能。
  • クライアント
    • HTTPサービスに対してのクライアント。リソースにアクセスするアプリケーションのこと。
  • リソースサーバー
    • HTTPサービスのこと。データや機能を提供するサーバーのこと。
    • リソースオーナーが許可したアクセスのみを受け入れる。
      • その受け入れ可否の確認手段がアクセストークン。
  • 認可サーバー
    • 認可サーバーの機能は以下の3つ。
      • リソースオーナーを認証する
      • クライアントのリソースへのアクセスについてリソースオーナーの同意を得る
      • アクセストークンを発行する
    • 具体的には以下の流れとなる。
      • リソースオーナーがGoogleアカウントにログインする。
      • リソースオーナーは「画像編集アプリがGoogle Photoにアクセスすること」について同意する。
      • 認可サーバー(GoogleのOAuthサービス)は「画像編集アプリにアクセス権の証として、アクセストークンを発行する」

3. OAuth tokens

認可サーバーからクライアントに向けて発行される。

  • アクセストークン

    • 以下の属性がある。
      • スコープ:誰がどのリソースにどのような操作を許可しているのか。
      • 有効期限:このトークンの有効期限はいつまでか。
    • OAuthの場合は、Bearerトークン。標準仕様は、RFC6750
  • スコープ

    • クライアントから認可サーバーへのリクエストの際に、スコープが指定される。
    • 読み込み権限、書き込み権限、シェア権限などの権限は必要最小限にとどめておくべき。
      • 悪用された際に、不正アクセスのスコープを狭めれるため。
  • 有効期限

    • 「アクセストークンの有効期限」<「リフレッシュトークンの有効期限」 の関係性になっている。
  • リフレッシュトークン

    • クライアントから認可サーバーに対してアクセストークンの再発行要求に利用される。
    • 注意:アクセストークンは、クライアントからリソースサーバに送られる。
  • 認可コード

    • 「リソースオーナーがクライアントへの権限移譲に同意した証」として発行される。
    • クライアントから認可サーバーに対してアクセストークンを要求する際に利用される。

4. OAuth endpoints

  • 認可サーバーが提供するURI

    • 認可エンドポイント
    • トークンエンドポイント
  • クライアントが提供するURI

    • リダイレクトエンドポイント
  • 認可エンドポイント

    • 認可サーバーのエンドポイントで、認可コードを発行するためのエンドポイント。
    • クランアントがアクセスして、認可コードが発行されると、クライアントのリダイレクトエンドポイントに送られる。
  • トークンエンドポイント

    • 認可サーバーのエンドポイント。
    • クライアントが認可コードともにトークンエンドポイントに送信することで、アクセストークンを取得できる。
  • リダイレクトエンドポイント

    • クライアントのエンドポイント。
    • 認可サーバが、レスポンスを返却すると、リダイレクトURIに認可コードをクエリパラメータとしてリダイレクトする。

5. Other - important keywords