RAKUS Developers Blog | ラクス エンジニアブログ

株式会社ラクスのITエンジニアによる技術ブログです。

トップ > かみせん > 認証アーキテクチャの更新について検討してみた

認証アーキテクチャの更新について検討してみた

かみせん

こんにちは。
株式会社ラクスで先行技術検証をしたり、ビジネス部門向けに技術情報を提供する取り組みを行っている「技術推進課」という部署に所属している鈴木（@moomooya）です。

ラクスの開発部ではこれまで社内で利用していなかった技術要素を自社の開発に適合するか検証し、ビジネス要求に対して迅速に応えられるようにそなえる 「技術推進プロジェクト」というプロジェクトがあります。

このプロジェクトで「認証」にまつわる検証を行ったので、その成果を共有しようかと思います。

なお半年前に書いた以下の記事の続きになりますので併せて御覧ください。

tech-blog.rakus.co.jp

認証関連の標準について

認可プロトコルのOAuth2.0や、SSOで用いられるSAMLなどがありますが、後方互換性の制約がなくこれから新しく構築するシステムであればOpenID ConnectとFIDO 2.0の組み合わせで対応することを最優先で検討しましょう。

OpenID Connect (OIDC)

複数の認証関連の標準を組み合わせていた状況からOpenID Connectに標準が集約されています。

NRI社製作の資料より抜粋

FIDO 2.0

いわゆるパスワードレス認証の標準です。

初めてサービスを利用する際にクライアントと鍵情報を登録することで、その後のサービス利用時には認証結果だけを通信し、クレデンシャル情報（ID/パスワードとか、指紋パターンとか）は通信せずに済む仕組み。

通信経路にもサーバーにもクレデンシャル情報を保持する必要がないため、万が一通信内容の盗聴や、サーバーデータの流出があった場合にもなりすまされる心配がない。

上図は非エンジニア向けに説明した資料から抜粋しているため「暗号鍵／復号鍵」となっていますが、SSHの鍵認証などと同様のいわゆる公開鍵暗号方式です。

認証サーバー（OP）ミドルウェア

現状ではKeycloakが最有力候補

OpenID Connect, FIDO2.0に対応した認証サーバーミドルウェアとしては

  • OpenAM
    • 2008年、OpenSSOとして米Sun社からリリース
      • 2010年、OpenAMとして米Forgerock社によりfork
      • 2018年、日OpenAMコンソーシアムによりfork
    • Javaによる実装
  • Keycloak
    • 2014年、JBossコミュニティよりリリース
    • Javaによる実装
  • ZITADEL
    • 2020年3月リリース
    • Go言語による実装
  • Casdoor
    • 2021年8月リリース
    • Go言語による実装
  • authelia
    • 2020年1月リリース？（3.7.0までしか辿れなかった）
    • Go言語による実装

といったものが現在存在しています。

ただし、このうちZITADEL, Casdoor, autheliaは検証開始当初は新しすぎた（機能も不足していた）ため検証対象としていません。 かなり活発に開発は進んでいるようなので、数年後に再評価するとしたら有力候補になっている可能性があります1。

特にZITADELはKeycloakの対抗馬となるべく意識しているようで、OIDC, FIDO2.0への対応はもちろん、マルチテナンシー対応、Identity Brokering機能（後述）などSaasでの利用を意識しているようです（vs Keycloak）。

OpenAM, Keycloakの比較

検討対象となったのはOpenAM, Keycloakです。

機能的には両者とも充実しています。

OpenAMについては普及度合いや枯れ具合は良かったものの、開発はセキュリティアップデート中心という状況であり、開発母体の規模に不安があったために採用を見送りました。最終リリースも2019年で止まっています。

Keycloakは現状でも活発に機能追加リリースが行われており、K8sなどコンテナ環境での利用も想定された設計になっているようなので将来性も問題ないと判断しています。

Keycloakの必要スペック

実験環境ではそれほど多くのスペックは要求されませんでしたが、環境構築当初VMのメモリをケチって128MBにしたら起動シーケンスでエラーを吐いて起動できませんでした。その後ちょっと余裕を見て512MBで動作させていましたが、512MBあれば今回の検証内容については全く問題なく動作していました。

Javaのアプリケーションはメモリを消費するイメージがありますが、メモリに関しては多めに確保するのが良いかもしれません。

サービス（RP）側ライブラリ

OpenID Connect用のライブラリはCertifiedなライブラリやUncertifiedなライブラリが公式で紹介されています。

openid.net

openid.net

Java

Java用のライブラリはOAuth2.0用のライブラリが拡張されて使われているという経緯から名前がわかりにくいのが難点です。

Spring(Spring Boot含む)を利用している場合は公式ページで紹介されているspring-boot-starter-oauth2-clientを利用しましょう。紹介ページではOAuth2.0での紹介となっていますが、OpenID Connectにも言及があります。

spring.pleiades.io

Springを利用していない場合はNimbus OAuth 2.0 & 2.1 SDK with OpenID Connect extensionsが現在もメンテナンスされているライブラリとなっています。

PHP

NRI社が総務省のプロジェクトの一環で作成したライブラリ実装。

OpenID Connect CertifiedなライブラリなのでPHPの場合はこちらを使うと良さそうです。

Node.js

OpenID Connect Certifiedなライブラリで後述しますが、Keycloakの公式からも言及されている（後述）ライブラリ。 Passport.jsと組み合わせて利用します。

個人が中心になって開発している部分に若干の不安はあるもののnode.jsではこちらが最有力。

注意点

実はKeycloakからも各言語用にOIDCアダプターとしてライブラリが提供されています。

しかしこれらは2023年にはおおかたサポート対象から外れる予定なので利用してはいけません。上述のライブラリ群から選ぶのが良いでしょう。

ちなみにNode.js用のライブラリについては2つ目の記事の中で

openid-clientが優れた代替手段であるように見えます。これはKeycloakが提供するOIDCアダプターよりも豊富な機能を持っています。

と触れられています。

認証アーキテクチャ

現状の課題

  • 現状はサービスごとに認証の実装、ID管理を行っている
  • 複数サービスを契約してもらうとID管理の負担が増えていく
    • 同じ会社のサービスなのだから一括で管理したいという自然な要求

検討しているアーキテクチャ構成

現状は各サービス内に持っている認証機能を外部のサービスとして切り出すことで認証機能を統一できないか検討しています。構成としてはオーソドックスな外出しですね。

ちなみに便宜上「楽楽認証（仮）」としていますが、新サービスとして提供する予定はありません。

楽楽認証（仮）は先述の通り、Keycloakをベースとしてラップするように管理サービスを用意してあげれば良いと考えています。今回は機能面の検証にフォーカスしていたため、ラップするサービス部分は構築していませんが実運用上はスタッフの操作手順を補助したり、ミスを予防するためにも内部向けのサービスとして構築すると思います。

顧客側認証サーバーを用いる場合

認証機能の外出しについてですが、現状でも一部のサービス（楽楽精算や楽楽販売、メールディーラーなど）では顧客側認証サーバーを利用する構成（いわゆるSSO構成）が可能になっています。

顧客側認証サーバーを使うかどうかは、当然顧客ごとに設定可能になっています。この場合に顧客によって「顧客側認証サーバーで認証処理を行うのか」「楽楽認証（仮）で認証処理を行うのか」という場合分けが必要になります。これに対応するためにラクスサービスから接続する先のサーバーを顧客ごとの設定に持たせることになりそうですが、外部接続先を切り替える実装は自前では行いたくないものです。

そこでIdentity Brokeringという機能が役立ちます。この機能を用いることで「ラクスサービス→楽楽認証（仮）→顧客認証サーバー」と認証処理をバケツリレーのように更に他の認証サーバーに委託することが可能になります。今回検証していたKeycloakにもIdentity Brokeringが備わっています。

Keycloakではマルチテナンシー機能の中でこのIdentity Brokering設定ができるようなので、顧客ごとに「楽楽認証（仮）」で認証するのか「顧客管理の認証サーバー」で認証するのか設定できそうです。 この機能についてはまだ継続した検証を行っているところなので、またの機会に触れられればと思います。

まとめ

  • OIDC + FIDO 2.0の採用
  • 認証サーバーはKeycloak
    • メモリは最低512MB確保
    • この記事が書かれたタイミング（2022年3月）から数年後に検討するなら新興ソフトウェア（ZITADELとか）も検討
  • 使用ライブラリはOpenID Connect公式が紹介しているものから選ぶ
    • Keycloakから提供されているものは使わない

認証部分はサービス運用上のクリティカルな部分（コケたらサービスが使えなくなる）なので、シビアに検討を重ねる必要があります2。共通認証基盤として利用するなら全サービスに影響が出るためなおさらです。

現状のままサービスごとに独立した管理にしておけば一度にすべてが使えなくなることはありませんが、どうしても利便性で劣ることになります。当然他社でも同じような動きがあると考えられるので、将来的には認証を共通化して利便性を上げる必要があると考えています。

その際には同時に多要素認証（MFA）やパスワードレスといった高いセキュリティ機能にも対応できると考えています。 　　

◆TECH PLAY
techplay.jp

◆connpass
rakus.connpass.com

  1. なぜ近年になってこんなに認証サーバーミドルウェアのリリースラッシュなのでしょうか？ あとサーバーサイドミドルウェアのGo言語人気がすごい……。↩

  2. Keycloakもクラスタリングに対応しているようですが検証はまだこれから。↩

ラクスの技術 / デザイン情報サイト
Copyright © RAKUS Co., Ltd. All rights reserved.