はじめに

Authlete（オースリート）社主催の勉強会『いまどきの OAuth / OpenID Connect (OIDC) 一挙おさらい』（2020 年 1 月 31 日（済）, 2020 年 2 月 21 日（中止））の内容がてんこ盛り過ぎるため、予習・復習用の情報を書き出そうと思います。

追記

2020 年 1 月 31 日の勉強会の資料と動画（字幕付き）を公開しました！

OAuth / OIDC

勉強会参加者は、OAuth 2.0（オーオース）と OpenID Connect（オープンアイディー・コネクト）の基本を知っていることが前提となります。

OAuth 2.0 は「アクセストークンを発行する仕組み」です。その中心となる仕様は RFC 6749 です。詳細については『一番分かりやすい OAuth の説明』と『OAuth 2.0 全フローの図解と動画』をご参照ください。

OpenID Connect は「ID トークンを発行する仕組み」です。その中心となる仕様は OpenID Connect Core 1.0 です。詳細については『一番分かりやすい OpenID Connect の説明』と『OpenID Connect 全フロー解説』をご参照ください。

PKCE / JWT

勉強会の案内文に次のように書かれている通り、

今回の勉強会では、主に「ポスト PKCE / JWT（2015 年以降）」を中心に、Authlete 社の独断と偏見により、2020 年に注目すべき OAuth 2.0 / OIDC 関連仕様とプラクティスをご紹介します。

2015 年に RFC 化された PKCE（ピクシー；RFC 7636）や JWT（ジョット；RFC 7519）は、2020 年の今となっては常識扱いされています。

PKCE は「認可リクエストの送信元とトークンリクエストの送信元が同一であることを認可サーバー側で確認するための仕組み」で、セキュリティ上必須級とみなされています。詳細については『PKCE: 認可コード横取り攻撃対策のために OAuth サーバーとクライアントが実装すべきこと』をご参照ください。

JWT は「署名 and/or 暗号化された JSON データ」です。JWT は OAuth / OIDC の様々な場所で使われているため、JWT を理解していないと詰んでしまいます。詳細については『IDトークンが分かれば OpenID Connect が分かる』をご参照ください。

BCP

OAuth / OIDC を実装する際のセキュリティ上のベストプラクティスが OAuth 2.0 Security Best Current Practice（通称 BCP）という文書にまとめられています。

同文書には、アクセストークンの対象リソースを制限する仕組みである Resource Indicators for OAuth 2.0（解説記事）や、tls_client_auth や private_key_jwt などの非対称鍵系クライアント認証方式（解説記事）、クライアント証明書とアクセストークンを紐づける仕組みである OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens（通称 MTLS）（図解）などへの言及が含まれています。

FAPI

より高いセキュリティのための要求事項をまとめた Financial-grade API（通称 FAPI；ファピ）の実装者向けドラフト第 2 版が 2018 年 10 月に承認されました。

認可リクエストの詐称・改竄防止のためのリクエストオブジェクト（紹介記事）、認可レスポンスの詐称・改竄防止のための ID Token as Detached Signature / Financial-grade API: JWT Secured Authorization Response Mode for OAuth 2.0 (JARM)（解説記事）、などの様々なセキュリティ向上策（リスト）が含まれています。

FAPI の詳細については『世界最先端の API セキュリティー技術、実装者による『FAPI（Financial-grade API）』解説』をご参照ください。

PAR / RAR

認可要求内容の詳細化（例：単なる「送金権限」ではなく「○○円を△△に送金する権限」）に対応するため、英国 Open Banking は Lodging Intent Pattern というものを考案しました。Lodging Intent Pattern では、認可リクエストを投げる前に認可要求内容を事前にサーバーに登録し、その登録内容に対応する Intent ID の発行を受け、続いて投げる認可リクエストにその Intent ID を含める、といった手順を踏みます。これにより、（Web ブラウザを介して投げられる）認可リクエストが巨大化することや、認可リクエストに個人特定情報などの繊細な情報が含まれることを防ぐことができます。

この Lodging Intent Pattern を汎用的な仕組みとして標準化すべく、OAuth 2.0 Pushed Authorization Requests（通称 PAR；パー）と OAuth 2.0 Rich Authorization Requests（通称 RAR；ラー）の仕様策定が進められています。

PAR は「認可リクエストを事前に認可サーバーに登録する仕組み」です。PAR をサポートする認可サーバーは Pushed Authorization Request Endpoint というエンドポイントを提供します。詳細については『図解 PAR : OAuth 2.0 Pushed Authorization Requests』をご参照ください。

RAR は「認可リクエストに詳細情報を含めるための仕組み」です。RAR をサポートする認可サーバーは authorization_details というリクエストパラメーターを解釈します。

Device Flow / CIBA

伝統的なリダイレクトに基づくフロー（解説記事）とは異なるフローとして、デバイスフロー（RFC 8628）や CIBA（シーバ）が新たに定義されました。

デバイスフローをサポートする認可サーバーはデバイス認可エンドポイントというエンドポイントを提供します。デバイスフローは、（認可エンドポイントではなく）デバイス認可エンドポイントにリクエストを投げるところから開始します。詳細については『図解デバイスフロー（RFC 8628）』をご参照ください。

CIBA をサポートする認可サーバーはバックチャネル認証エンドポイントというエンドポイントを提供します。CIBA フローは、（認可エンドポイントではなく）バックチャネル認証エンドポイントにリクエストを投げるところから開始します。詳細については『世界最先端の認証認可技術、実装者による『CIBA』解説』をご参照ください。また、CIBA の実装方法については『Authlete を使って CIBA 対応の認可サーバーを作る』をご参照ください。

^{↑ CIBA の概念図}

IDA

運転免許証や健康保険証などを本人確認書類として用い、物理的な対面などで本人確認をし、その結果得られた氏名や住所などの情報があるとします。その情報を、本人確認書類や本人確認方法の情報と併せて提供することが求められる場合があります。その提供方法を標準化したものが、OpenID Connect for Identity Assurance 1.0（通称 IDA）です。IDA は、本人確認、いわゆる KYC（Know Your Customer）が求められるシーンでの活用が期待される技術仕様です。詳細については『Identity Assurance - eKYC 時代の OpenID Connect』をご参照ください。

{
  "email": "[email protected]",
  "verified_claims": {
    "verification": {
      "trust_framework": "de_aml",
      "time": "2012-04-23T18:25:43+01",
      "verification_process": "676q3636461467647q8498785747q487",
      "evidence": [
        {
          "type": "id_document",
          "method": "pipp",
          "document": {
            "type": "idcard",
            "issuer": {
              "name": "Stadt Augsburg",
              "country": "DE"
            },
            "number": "53554554",
            "date_of_issuance": "2012-04-23",
            "date_of_expiry": "2022-04-22"
          }
        }
      ]
    },
    "claims": {
      "given_name": "Max",
      "family_name": "Meier",
      "birthdate": "1956-01-28"
    }
  },
  "iss": "https://authlete.com",
  "sub": "1003",
  "aud": [
    "213488672826"
  ],
  "exp": 1580982513,
  "iat": 1580896113,
  "auth_time": 1580896112,
  "nonce": "mynonce",
  "at_hash": "J780SH6dR2lHc0ivg6PAnA",
  "c_hash": "KpIgI65bQORt526n1tOrng",
  "s_hash": "w2g5TwGcVl39IiV2dzcn5w"
}

^{↑ IDA で定義される verified_claims を含む ID トークンのペイロード部の例}

おわりに

2020 年 2 月 2 日の夜、共用サーバー（api.authlete.com）の Authlete のバージョンを 1.1 から 2.1 に更新しました（アナウンス）。これにより、新しい OAuth / OIDC の仕様を試していただけるようになりました。特に、FAPI、MTLS、CIBA は注目です。なお、PAR、RAR、IDA は Authlete 2.2 以降でのサポートとなるので、共用サーバーでは利用できません。Authlete のバージョンごとの仕様サポート状況については、スペックシートをご確認ください。

Authlete 社は、FAPI、MTLS、CIBA、PAR、RAR、IDA などの最新仕様の策定作業に深く関わった上で実装をおこなっています。そのため、これらの最新仕様について多くの知見を持っています。これらの最新仕様を利活用されたい場合は、是非 Authlete の採用をご検討ください。お問い合わせはコンタクトフォームまたはメール（[email protected]）でお願いします。

^{↑ Authlete 社の勉強会に参加するともらえる定規。認可フローのシーケンス図を描くときに便利？！}