OSS Consortium


 

日本語 | English

開発基盤部会 Blog

開発基盤部会 Blog >> Article details

2018/05/28

OAuth2 / OpenID Connect課題解決 備忘録 3

Tweet ThisSend to Facebook | by nishino
前回に続き、OAuth2 / OpenID Connect課題解決 備忘録の第3回です。

 今回のテーマは、
  「PKCEをサポートしない場合Client側で疑似PKCEする。」
 です。

<経緯>

 Open棟梁 - 汎用認証サイトでは、v01-10で「OAuth PKCE」をサポートしました。ソレに合わせたように、汎用認証サイトの導入案件でスマホ認証の要件がでてきたのですが、「OAuth PKCE」サポート前のIdP/STSのアップデートに予算が必要なため、アプリ側で対応しようという話になり、下記のような「疑似PKCE」のフローを作成してみました。

<疑似PKCEのフロー>

  1. Resource Owner(ユーザ)がスマホ上のアプリをクリックする。
  2. Client(アプリのスマホ側)が起動する。
  3. Client(アプリのスマホ側)のログインをクリックする。
  4. 外部ブラウザ起動し、Client(アプリのサーバ側)へアクセスする。
    ☆ CSRF対策、カスタムURLスキーム上書き攻撃対策として、
    Client(アプリのスマホ側)はstateに加えcode_verifierパラメタ付加。
    ※ stateとcode_verifierパラメタは後で使用するので保存しておく。
[ここからOAuth2のAuthoriaztion Codeフローでの認証]
  1. Client(アプリのサーバ側)は、Authorization Serverへリダイレクト
    (OAuth2のAuthoriaztion Codeフローを開始する)
    ☆ CSRF対策として、Client(アプリのサーバ側)は、
     Client(アプリのスマホ側)から渡されたstateパラメタ付加。
  2. Authorization Serverがログイン画面を表示する。
  3. Resource Owner(ユーザ)がCredentialを入力する。
    ※ 認証用途なので認可画面表示はスキップする。
  4. Authorization ServerはAuthoriaztion Codeを発行し
    Client(アプリのサーバ側)のRedirectエンドポイントへ、
  5. Client(アプリのサーバ側)は、
    • stateパラメタを検証し、
    • Authorization ServerのTokenエンドポイントへ
      Authoriaztion Codeを提示する。
  6. Authorization Serverは、Authoriaztion Codeを確認し、
    Client(アプリのサーバ側)へAccessトークン発行する。
[ここまでOAuth2のAuthoriaztion Codeフローでの認証]
  1. Client(アプリのサーバ側)は、Accessトークンを使用し、Authorization Serverのユーザ情報エンドポイントから
    ユーザ情報を取得し、当ユーザのアクセス権限を取得する。
  2. 権限があれば、
    • Client(アプリのサーバ側)の
      スマホ認証用のエンドポイントへリダイレクト。
    • Client(アプリのサーバ側)のスマホ認証用のエンドポイントで、
      • 一時codeを生成してcode_verifierと紐つけて保持する。
      • そして、Client(アプリのスマホ側)へリダイレクトする。
        ☆ カスタムURLスキームで一時codeとstateを渡す。
    • Client(アプリのスマホ側)は、一時codeとstateを受け取り、state検証したら、一時codeと、④で指定したcode_verifierを Client(アプリのサーバ側)のスマホ認証用のエンドポイントへポストする。
    • Client(アプリのサーバ側)のエンドポイントは
      codeとcode_verifierを検証し、認証用tokenを発行する。
    • Client(アプリのスマホ側)は、認証用tokenを取得する。
    • ログイン後、Client(アプリのスマホ側)は、認証用トークン
      を使用してWeb APIへアクセスして情報を取得・更新する。
  3. 権限なしであれば、
    • Client(アプリのサーバ側)のエラー画面へリダイレクト。
      これにより、外部ブラウザ上にエラー画面が表示される。

<感想>

 ...と、かなり複雑...と言うか、長くて大変な処理をOAuth2 Client(≒Webアプリケーション)毎に個別に組み込む必要があることが解りました。コレはかなりの手間ですし、所詮は「オレオレ仕様」なので、こんな対応は絶対にやりたく無いですよね。
 ということで、やはり、スマホ認証を行う場合は、 「OAuth PKCE」をサポートしたIdP/STSにアップデートするのが良いかと思います。
 また、「OAuth2 / OpenID Connect」界隈は、「OAuth2拡張」、「Financial-API」プロファイルなど、早いスピードで追加の仕様がリリースされているので、IdP/STSのアップデートの予算は、先読みして獲得しておいたほうがイイように思います。
09:00 | Impressed! | Voted(0) | Comment(0) | ご報告