Life is ...

OAuth

  • OAuth は API 認可の技術
    • OAuthはあくまでも認可の仕組みであり、認証には関係無い、というのが正式な立場
  • OAuth を使う目的は、OAuth アクセストークンを取得して、ユーザやアプリのために API リクエストを行うこと
  • SAML との違いは個人の情報の扱い方
    • SAML
      • 個人に信頼されているので、認証が通ればアプリ側に情報を渡す
    • OAuth
      • 個人に対して情報をアプリに出してよいかの確認ポップアップ画面が表示される
  • アクセストークンをいかにして取得するかが重要

OAuth 1.0

  • ユーザ名やパスワードを共有することなく、リソースオーナーに代わってサーバリソースアクセスすることを認可してもらうための規約

  • spec

  • 特徴

    • サーバサイドアプリ向け
      • そもそもサーバサイドの Web アプリケーションを想定した規約
      • デスクトップやスマホ等の端末サイドアプリ向けに設計されていない
    • シークレット秘密管理
      • シークレット情報が漏洩することなく秘密管理できることが必須要件
      • シークレット情報
        • OAuth サーバが OAuth クライアントやリクエストを認証するための秘密の文字列
    • 署名 Signature
      • OAuth プロバイダへのリクエスト時、リクエストデータに署名を付ける
    • Authorization Header
      • OAuth プロバイダへのリクエスト時、Authorization ヘッダの OAuth スキームを使用
    • SSL/TLS 不要
      • 転送路の暗号化が必須ではない
        • シークレット情報は秘密管理されておりクライアントしか知らない
        • クライアントしか知り得ないシークレットキーによる署名を検証することで、なりすましや改ざんが見破れる
        • データに timestamp と nonce を含めており、これをチェックすることで、リクエストのリプレイアタックが防げる
  • 課題
    • サーバサイドのアプリ向けに策定されたプロトコルのために、次のようなアプリでは実装が難しい
    1. デスクトップやスマホ等の端末アプリ
      • OAuth 2.0 で対応
    2. 端末(フロントエンド) + サーバ(バックエンド) 構成のアプリ
      • OpenID Connect で対応
    • 安全ではあるが署名の作業負荷がある
      • OAuth 2.0 で署名が不要に

OAuth 2.0

  • 使用目的

    • OAuth アクセストークンを取得して、ユーザもしくはアプリ自身のために、そのアクセストークンを使って API リクエストを実行すること
    • アクセストークンを取得できれば、そこで認可されたリクエストは実行できる
    • ユーザ名やパスワードを共有することなく、リソースオーナーに代わってサーバリソースアクセスすることを認可してもらうための規約

  • OAuth 1.0 と OAuth 2.0 では互換性はない

    • 共存は可能

  • spec

  • 特徴

    • 端末アプリに対応
      • 端末サイドのアプリを考慮したフローが追加
      • Client Type という仕様
        1. Confidential
          • サーバサイド Web アプリ
          • シークレット情報を安全に秘密にできる OAuth Client
          • Authorization code Flow を使用
        2. Public
          • 携帯サイドアプリ
          • デスクトップやスマホネイティブアプリなどのように、シークレット情報を秘密にできない OAuth Client
          • Implicit Flow を使用
    • SSL/TLS による暗号化が前提
      • その分規約がシンプルに
    • 署名が不要
      • SSL/TLS に依存
    • シークレット情報の扱い
      • シークレット情報も HTTP message で普通に送受信する
        • ただし、Client Type が Confidential の OAuth Client に限る
        • Public な OAuth Client はシークレット情報を秘密に出来ない
      • シークレット情報
        • OAuth サーバが OAuth クライアントを認証するために発行する秘密の文字列
          • OAuth サーバと OAuth クライアントだけが知りうる情報であり、これが漏洩すると悪意のあるアプリから容易になりすましされるので注意
    • Authorization Header

      • Token を Authorization Header の Bearer スキームに付与

        GET /resource/1 HTTP/1.1
Host: example.com
Authorization: Bearer mF_9.B5f-4.1JqM
    • Access Token 寿命が短い
      • 数分〜数日程度で期限切れとなる
      • 特に Implicit Grant Flow で取得した access token の寿命は数分程度に短くすべき
        • このために token をリフレッシュするためのフローが追加されている
    • リソース操作は規約外
      • Access token を取得するまでを標準化したプロトコル

OAuth 2.0 Flow

  1. Authorization Code Flow
    • サーバサイドアプリ
  2. Implicit Flow
    • 携帯サイドアプリ

  • 登場人物

      • リソースオーナー（Resource Owner）
        • API 認可を必要とするアプリのユーザ
      • OAuth Client
        • API プロバイダーが提供する API にアクセスすることで何らかのサービスを提供する主体
        • Authorization Code Flow ならサーバで動くアプリ
        • Implicit Flow ならブラウザで動くアプリという認識
      • Authorization Server と Resource Server
        • 多くの場合、同じ事業者によって運営されており、かつ同一サーバー内に共存していることも多い
        • Authorization Server
          • エンドユーザーの認証・トークンの発行などを担当
        • Resource Server
          • Authorization Server が発行したトークンを受け入れて実際の API を提供するサーバー

  • 課題

References