こんにちは。 株式会社ラクスで先行技術検証をしたり、ビジネス部門向けに技術情報を提供する取り組みを行っている「技術推進課」という部署に所属している鈴木（@moomooya）です。
ラクスの開発部ではこれまで社内で利用していなかった技術要素を自社の開発に適合するか検証し、ビジネス要求に対して迅速に応えられるようにそなえる 「技術推進プロジェクト」というプロジェクトがあります。
2021年度は通年で「ユーザー認証」について取り組んでいるので、途中ではありますが紹介したいと思います。
■ 昔ながらの認証
設計概要
まずは古き良き時代の認証ですが、定番の設計としては以下の様なものではないでしょうか。
クレデンシャル情報の保持
- IDとパスワードを入力
- 場合によっては秘密の質問を追加で設定
- 本質的にはIDとパスワードが2セットあるのと同じ
- 場合によっては秘密の質問を追加で設定
- サーバーサイドでパスワードを非可逆変換した文字列を保持
- ハッシュ関数を使うのが一般的
認証処理
- ユーザーが入力したIDとパスワードをサーバーに送信
- サーバーサイドでパスワードを同じハッシュ関数で変換
- IDと、パスワードを変換した文字列同士を比較して一致すれば認証成功
問題点
で、こういったIDとパスワードだけの認証が問題視され始めています。
よくある記事ですが、ユーザーがパスワードを決める以上パスワード自体に脆弱性があるということなのだと思います。 流石にこのレベルのパスワードは「英数大文字小文字」に加えて「記号を含むこと」くらいの制限かけていれば避けられますが、ターゲットのユーザー層の想定リテラシレベルによっては記号入力を必須にできない場合もあると思いますし、本質的にな解決ではないでしょう。
関連して、海外の調査会社もこの様な記事で多要素認証市場が年平均15％成長するとしています。
■ 用語解説
「多要素認証」というワードが出てきましたが、認証の話題では間違って言葉を使っている人も結構います。なのでまずは主だった用語をおさらいしていきたいと思います。 最初は定番ですが「認証」と「認可」の違いから。
| 認証 | 認可 |
|---|---|
| ユーザーが「誰」であるか確認すること | ユーザーが「何を出来る」か権限を与えること |
次に「多要素認証」と「多段認証」の違い……と言いたいところですが、その前提として認証に用いる情報の分類を先に説明します。
| 知識情報（知識要素） | 所持情報（所持要素） | 生体情報（生体要素） | |
|---|---|---|---|
| 概要 | ユーザーが知っている情報 | ユーザーが持っている物の情報 | ユーザーが自身の情報 |
| 例 | パスワード、秘密の質問、Androidのロックパターン | PC、スマホ、USBセキュリティキー | 指紋、網膜、声紋、歩行パターン、タイピングの癖 |
これらの認証に用いる情報のことを「クレデンシャル情報」といいます。
そして、これらを前提として
- 多要素認証
- 上記3種類の情報から2種類以上を組み合わせた認証のこと
- 必然的に多段認証となる
- 多段認証
- 上記3種類の情報によらず、2種類の認証を組み合わせた認証のこと
- 「パスワード」＋「秘密の質問」はどちらも知識情報だが、多段認証となる
関係性としてはこんなイメージです。
ただ、紛らわしい用語といして「パスワードレス認証」があります。おそらく原義的な意味では「知識情報以外による認証」という意味だったと思うのですが、今日では実質的に多要素認証を指している様です。注意しなければいけないのは「パスワードレス認証＝生体認証（生体情報を用いた認証）」とは限らないということです。
■ 認証に関する仕様
認証に関連する仕様としては
といろいろありますが、既存環境との互換性などの考慮が不要であれば現状では OpenID Connect と必要に応じて FIDO 2.0 の組み合わせが無難だと判断しています。判断した理由と併せて、それぞれの比較検討をまとめてみます。
OpenID Connect
OpenID Foundationによって規定されている認証認可に関する仕様です。OpenIDとOpenID Connectは別物なので注意、略す場合はOIDCと略すのが一般的です。
ざっくりいうと既存の仕様を統合して規定された仕様になります。詳細はOpenID Foundation Japan 工藤氏のスライド（各仕様との関係性については33スライド目）が詳しいです。
OpenID ConnectとOAuth2.0の違い
先述のスライドにある様にOpenID ConnectはOAuth 2.0を拡張した仕様でもあります。OAuth 2.0の挙動である
という挙動はOpenID Connectにも仕様として含まれています。さらにOpenID Connectではさらに
という挙動も規定されています（選択可、OpenID Connectを利用する場合はIDトークンを使う方が一般的だと思います）。
IDトークンには
- 「誰」が認証されたか
- 「どのサーバー」で認証されたか
- 「いつ」認証されたか
- 「どの様な基準」で認証されたか
- 認証されたユーザーの「属性情報（姓名、メールアドレスなど）」
が含まれています。 OAuth 2.0は「認可の仕様であって認証の仕様ではない」と言われますが、OAuth 2.0ではIDトークンは規定されていないので「誰についての認可コードなのか」はわからない（OAuth 2.0の外で認証は行う前提）のです。
この辺りの挙動の説明についてはAuthlete 川崎氏の動画解説が詳しいです。
IDトークンについては同氏のQiita記事も併せて確認すると良いでしょう。
OpenID ConnectとSAMLの違い
シングルサインオン（SSO）を実現する仕様として SAML がよく使われますが、OpenID Connectでも実現でき近年はGoogleやFacebook, GitHubなど着々と OpenID Connect でのSSOに対応するサービスが増えてきました。
前述の通り OpenID Connect は SAML の流れも組んでいますが、SAML はその生い立ちから社内ネットワーク1での利用を想定しています。そのため SAML での認証処理はユーザーの同意を必要とせずに処理することができます。認証処理は信頼されているサービスで行われるという前提です。
社内サービスの間でのみ用いられる場合であれば問題ありませんが、社外のサービスとの間でもSSOするのであればユーザーの同意処理は挟みたいところです。
あとは実装者の観点でいくとSAMLがXMLベースの通信フォーマットなのに対して、OpenID ConnectはJSONベースの通信フォーマットとなります。
FIDO 2.0
FIDO Allianceによって規定されているパスワードレスに関する仕様。
FIDO 1.0ではFIDO UAF, FIDO U2Fという2つの仕様から構成されていましたが、それぞれPaypalとGoogleが推進していて、さらにAppleが別仕様としてTouchIDを推進するという分断状態だったようです。そしてこの状況を解決するためにFIDO U2Fをベースとして、FIDO 2.0が規定されました。
FIDO 2.0は大きく2つの仕様によって構成されています。
| WebAuthn | CTAP2 |
|---|---|
| サーバーとクライアント間の通信プロトコル。W3Cに提案されRFCとして標準化。 | クライアントと認証デバイス間の通信プロトコル。FIDO Allianceにより規定。 |
特徴としては、FIDO 2.0ではサーバーとクライアントの間でクレデンシャル情報を直接通信することがないことです。FIDO 2.0ではクライアントサイドで認証処理を行なった結果のみをサーバーに送信します。これにより通信経路からのクレデンシャル情報の流出を避けることができます。
ちなみにFIDO U2Fが改名されてCTAP1となっています。
OpenID ConnectとFIDO2.0の位置関係
OpenID ConnectとFIDO 2.0の関係は以下の様になっています。
OpenID Connectはサービス間（サーバー間）での認証プロトコル2、FIDO2.0はサーバーとクライアントの間で認証情報をやり取りするWebAuthnとクライアントと認証デバイスの間で認証処理を行うCTAP2となります。
FIDO2.0の対応状況
FIDO 2.0はクライアントサイドで動作するため対応するOSとブラウザが必要になります。2021/10現在では主な環境では対応済みです。
- OS
- ブラウザ
■ 認証サーバーソフトウェア
OpenID ConnectやFIDO 2.0はそれぞれ多くの仕様によって詳細が規定されています。これらをゼロから実装するのはサービスの開発効率として非現実的です3。
認証サーバーとして利用できるミドルウェアとしてOpenAMとKeycloakがあります。どちらもOSSですが概要を調べてKeycloakを試すことにしました。
- OpenAM
- Keycloak
OpenAMとKeycloakの比較についてはNRI 和田氏の以下スライドが詳しいです。タイトルでは翻訳プロジェクトの紹介となっていますが、前半部分はOpenAMからKeycloakへの移行プロジェクトについて書かれています。
■ まとめ・下半期の予定
さてここまで2021年上半期で調査検討した内容をまとめました。引き続き下半期では以下のような検証を行っていこうと考えています。
- 実際に検証用のシステムを構築して運用を想定した検証
- Keycloakはどの程度サーバースペック要求するのか検証
- Keycloakでのユーザー属性情報の管理はできるのか、ユーザー属性に独自項目の追加はできるのか
- クライアント側の認証手法によって挙動や運用に差異が出ないか
それではまた下半期末に検証の結果をまとめたいと思います。 認証技術の調査や選定を行なっている方の助けになれれば幸いです。
エンジニア中途採用サイト
ラクスでは、エンジニア・デザイナーの中途採用を積極的に行っております！
ご興味ありましたら是非ご確認をお願いします。
https://career-recruit.rakus.co.jp/career_engineer/カジュアル面談お申込みフォーム
どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。
以下フォームよりお申込みください。
rakus.hubspotpagebuilder.comラクスDevelopers登録フォーム
https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/イベント情報
会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！
◆TECH PLAY
techplay.jp
◆connpass
rakus.connpass.com
