Dongri Jin

ARIGATOBANKのエンジニアの金です。
2021年1月にARIGATOBANK社に入社した時はプロダクトとして解決する課題の特定や仮説検証の段階でしたが、全体構想には複数のサービスを組み合わせるイメージがあり、そのための下準備から始めることになりました。

CTOと話した結果、会員情報を安全に管理するのと、強度の高い認証レベルをサービス横断で実現するための統合ID基盤を先行して作ることになりました。

IDaaSを使うか?自前で作るか?

世の中にID管理サービスも多数存在します。初期設計の段階ではサービスのビジネス側の実装にフォーカスするためにIDaaSを採用することを検討していましたが、当社で必要とするユースケースへの対応の難しさや、ROIの考え方など悩むポイントが多岐にわたりました。悩むだけではしょうがないのでとりあえずプロトタイプを作ってみて動くものを見ながら話ししたくて、手を動かしてプロトタイプを作ることにしました。

自前で作るのもOSSを使ってカスタマイズするのとフルスクラッチで作るのがあると思いますが、OSSにした場合、非常に大きなメリットがある反面、機能追加や変更のコントロールが難しくなるため、フルスクラッチで作ることにしました。

OpenID Connectを採用

昨今では認可プロトコルは OAuth 2.0 を採用するのが一般的だと思いますが、当社では OpenID Connect を採用しました。OpenID Connect は OAuth 2.0 の拡張で、OAuth 2.0 での安全な認可シーケンスをベースに、IDトークンを介してユーザー情報や認証情報を取り扱うことができます。

当社では、OpenID Connect を前提にした認証・認可・情報連携が、その他の方法に比べてお客様の情報を安全に取り扱うセキュアなアーキテクチャになると判断され、OpenID Connect の採用に至りました。実際の方式としては OAuth 2.0 with PKCE + OpenIDConnect です。

いくつか特徴的な項目についてご紹介します。

  • 認可タイプ
    認可タイプにはいろんなタイプがありますが、一番安全な、認可コードフローで実装しました。
  • stateパラメータ
    CSRF(クロスサイトリクエストフォージェリ)対策で使用されるパラメータですが、必須項目にして、uuidレベルのユニーク性を持たせる仕様にしました。
  • nonceパラメータ
    リプレイアタック対策でnonceパラメータを必須にしました。RPが必ず検証するようにしてます。
  • PKCE (Proof Key for Code Exchange by OAuth Public Clients)
    認可コード横取り攻撃対策でPKCEを対応しました。 code_challenge_method を plain ではなくより安全な S256 にしました。
  • キーローテーション
    IDトークンの検証に用いる公開鍵を一定時間でキーローテーションするようにして、より安全な検証を行えるようにしました
  • ACR(Authentication Context Class References)による認証レベルの制御
    特定機能にアクセスする際に追加認証としてパスワードの再確認やSMS認証を追加するユースケースを想定し、IDトークンに含まれるACRの値で認証レベルを制御を行う実装としました。

--

--