パスキーのテストサイトがリニューアル

こんにちは、富士榮です。

以前も何度かWebAuthnのテストをするためのサイトを紹介しましたが、今回Okta（Auth0）がパスキー学習サイトをリニューアルしてきたので試してみます。

https://learnpasskeys.io/ja

なんと日本語に対応しています。

ユーザIDやユーザ名など登録に使う情報はあらかじめ決まっていますが、デモとして試すこともできますし、API仕様などを含むリソースもまとまっています。

スクラッチで実装する人も、パスキーを基礎から学習したい人にもとても良いサイトなのでぜひアクセスしてみると良いと思います。

Okta AD/LDAP DelAuthモジュールに関する脆弱性

こんにちは、富士榮です。

Okta社よりAD/LDAP DelAuthモジュールに関する脆弱性が報告されていますね。

https://trust.okta.com/security-advisories/okta-ad-ldap-delegated-authentication-username/

報告されている内容としては、AD/LDAP DelAuthモジュールを使っている環境で、過去にキャッシュログインに成功したことのある場合、ユーザー名が52文字以上だとパスワードなし（キャッシュのみで）ログインが成功してしまう、という話です。

こちら上記のサイトからの引用です。

On October 30, 2024, a vulnerability was internally identified in generating the cache key for AD/LDAP DelAuth. The Bcrypt algorithm was used to generate the cache key where we hash a combined string of userId + username + password. During specific conditions, this could allow users to authenticate by only providing the username with the stored cache key of a previous successful authentication.

Note: A precondition for this vulnerability is that the username must be or exceed 52 characters any time a cache key is generated for the user.

2024年10月30日、AD/LDAP DelAuthのキャッシュキーの生成において、内部的に脆弱性が確認されました。キャッシュキーの生成には Bcrypt アルゴリズムが使用され、userId + username + password を組み合わせた文字列がハッシュ化されます。特定の条件下では、ユーザー名と、過去に認証に成功した際に保存されたキャッシュ・キーだけを提供することで、ユーザーが認証できる可能性があります。

注：この脆弱性の前提条件として、キャッシュ・キーが生成される際には、ユーザー名が52文字以上でなければなりません。

すでにOktaのプロダクション環境では解消されているようですが、本モジュールを利用している場合（特にAD連携をしている場合はほぼ必ず使っているはずのモジュールなので）は、ユーザ名が52文字以上あるユーザがいるかどうか、侵入の痕跡がないか、など確認しておいた方が良さそうです。タイムラインを見ると脆弱性のあるモジュールがリリースされたのが2024/7/23で、発見されて対応されたのが2024/10/30となっており気が付かないまま３ヶ月経過しているので。

そもそも論としてAD/LDAP DelAuthってなんだ？って人もいると思うので簡単に。

要するに、クラウド上にあるOktaへオンプレのADやLDAPのパスワードを使ってログインできるようにするモジュールです。

AD版はこちら

https://help.okta.com/en-us/content/topics/security/enable_delegated_auth.htm

LDAP版はこちら

https://help.okta.com/en-us/content/topics/security/security_authentication.htm

ざっくりとした仕組みですが、Oktaへの認証要求があるとオンプレのAD/LDAPへ認証要求が行われ、成功するとパスワードハッシュのキャッシュがOktaクラウド側に置かれ、以降キャッシュが有効な間はオンプレ側への問い合わせなしにクラウド側だけで認証処理が行われる、という感じです。

すでに対応は終わっているとは言えなかなかな脆弱性ですね。。。

まぁ、ユーザ名が52文字以上って言うのもあんまりないとは思いますが。

[Auth0/Okta CIC]ログインに使う識別子にメールアドレス・ユーザ名・電話番号を使う

こんにちは、富士榮です。

たまにはAuth0/Okta CICを。

Auth0/Okta CICはログインする時の識別子はデフォルトでメールアドレスになっています。

これをユーザ名や電話番号を使うように設定することもできます、という話です。

ドキュメントはこちらにありますので、実際に設定する場合は注意点を含めこちらをみてください。

https://auth0.com/docs/authenticate/database-connections/flexible-identifiers-and-attributes

設定は簡単です。

ユーザ名とパスワードでの認証するコネクター「Username-Password-Authentication」の設定を開きます。

この中にAttributesというタブがあるので開きます。

するとNew Attributes ConfigurationがあるのでActivateします。（デフォルトはEmailのみってことですね）

確認されますので、Proceedを選択して進めます。

すると「Add Attribute」というボタンがアクティブ化されます。

クリックすると識別子として利用する属性を選択するポップアップが出ます。ユーザ名もしくは電話番号が選択できるようになります。

ユーザ名を選択すると関連する設定を行うことができます。

- ユーザ名を識別子として使うかどうか

- ユーザ名を使ってサインアップすることを許可するか（オプションか必須か）
- ユーザプロファイルとしてユーザ名を要求するか

- ユーザ名の文字列の長さ

また、詳細設定ではメールアドレス形式でユーザ名を許可するかの設定もできます。（現時点では電話番号形式のユーザ名は使えません。まぁ、正直どういうシナリオで使うのか不明ですが）

設定を終えるとログイン画面の入力ボックスに「ユーザー名またはメールアドレス」という形で表示が変わります。

また、サインアップ画面でもメールアドレスに加えてユーザー名も要求されるようになります。

なお、電話番号の方も似たような設定を行います。

設定が終わるとログイン画面が「電話、ユーザー名、またはメール」という表示に変わります。

サインアップ時に電話番号も入力が求められるようになります。

システムを移行する時など、複数の形式の識別子が混在するケースもありますので、そういうケースでは使えそうな機能ですね。

一方で通常はあんまり複数の形式のログインIDを有効にしておくとユーザも混乱しそうなので、割り切りも必要だと思います。

Auth0 Ambassadorプログラム

こんにちは、富士榮です。

Auth0がOktaの一部となり一つの時代が終わったなぁ、とAuth0 Ambassadorの一人としても感慨に耽っていたここ3年くらいですが、諸々のプログラムが終わっていくのは寂しいものです。

ということでAuth0 Ambassadorプログラムはまだページは残っていますが終了していますね。

https://auth0.com/ambassador-program

少し前のことですが、プログラム終了に伴い記念メダルをもらいました。

色々と面白いプログラムだったので少し寂しい思いはありますが、Auth0改めOkta CICはたまに触っていこうと思います。

ちなみに、Market Placeって仕組みもあり、某社がこんな感じでIdentity VerificationのActionを公開していますよ。

Auth0の管理画面へのログインにパスキーを使うと少しハマる件

こんにちは、富士榮です。

そういえばAuth0（Okta CIC）の管理画面へのログインにパスキーなどが使えるので使ってみたいと思います。

ちなみにちょっとだけ癖があります。簡単に書くと、

• パスキー追加をメニューから実施する場合はplatform認証器は選べない
• USBキーやOTPなど多要素認証を追加し利用すると「このデバイスでのログインの高速化」を目的としてplatform認証器の登録を促される
• リカバリはリカバリーコードを利用する
• どうやらパスキーとしてはUSBなど外部キーを前提に設計されている
• デバイス登録を目的にplatform認証器登録も使えるが同期される前提はなさそう

という感じです。最初からplatform認証器が登録できればいいのに。ちょっと実装が古いのかな。

さて、始める前に基本的な話を。IDaaSを使ってID基盤を構築するときに忘れてはいけないのはIDaaS自体の認証強化とアクセス制限です。

最低限やっておくべきことは、

• 管理者アカウントの分離（共有ユーザの排除）
• 管理権限の適正化
• 認証強化（多要素認証）
• ※API実行ユーザも忘れずに！

くらいでしょうか。

特にヘルプデスクやオペレータのアカウントも作る必要もあると思うので適切に権限分離は重要だと思います。

また、日本企業に多いと思いますが、上記に加えてアクセス元の環境の制限（IP制限など）も行いたい、という話も出てくることもあります。（これは働き方改革なのか、ネットワークペリメーター神話がまだまだ生きているだけなのかはケースバイケースです）

ということでAuth0でも管理画面へのログイン時の認証を強化できますのでやっておきましょう。

ちなみに、ご存知の通りAuth0の管理画面へログインするためにはローカルログインに加えてLinkedInやMicrosoft Account、Githubアカウント、Googleアカウントが使えます。

当然、それらのIDシステムもパスキーに対応していたりと認証強化を行うことは可能ですが、今回のテーマはAuth0側でさらに認証強化をする、という話です。

IdP側の認証強化の結果をこのケースおけるRPとなるAuth0の管理画面はどこまで信じることができるのか？と言う話とUI/UXの関係については別途書こうと思いますが、ざっくり言うと外部IdP（ここで言うとGoogleなど）は認証結果に対する責任は取ってくれない、かつどのような認証手段で認証したのかは教えてくれないので、重要な顧客IDを預かるIDaaSは自前でも多要素認証を実装しておくことが重要です。

ログインしてプロファイルページを開くと認証手段の追加ができます。

ちなみに設定が行われいていないテナントでは順次ログイン時に強制的に多要素認証設定を行うように促されるため最近のテナントを持っている方は設定済みかもしれません。

ということで追加してみます。WebAuthn with FIDO Security Keysをクリックしてみましょう。（なお、ポップアップがブロックされているとエラーになりますので、許可してください）

登録画面が出てきますね。初めに書いた通りplatform認証器ではなくUSBセキュリティキーが前提となっています。

登録が終わるとリカバリーコードが発行されるのでコピーしておきます。ちなみにダッシュボードからリカバリーコードは再生成できますので、こちらのスクリーンショットのコードはすでに無効です。

これで登録が完了しました。

一旦ログアウトしてログインし直してみます。USBキーが求められます。

すると、「このデバイスでのログインを高速化」と言われます。

そしてTouch IDが求められます。

USBキーとデバイスの両方が登録された状態になります。

USBキーを使う場面は少なくともSyncされたデバイスでは出番はなさそうです。

どうもplatform認証器はあくまでデバイス登録を目的としたものとして整理されているようですね。

しかし、iCloudで同期されているのかと思いつつiPhoneでダッシュボードにログインしてみるとplatform認証器は使えません。

USBキーが求められるので、仕方なく先ほど登録したUSBキーを使ってログインします。（先ほどYubikey NFCを使ったのでNFCで読み込ませました）

するときました。先ほどMacで登録したのと同じようにログインの高速化。

FaceIDを使ってデバイス登録を求められます。

しかし、すでにデバイス登録をMacでしているのでエラーが出ます。。。

iCloudで同期されているので登録済みって言われてます。

やはりパスキーが同期されている想定はなく、あくまでplatform認証器はデバイス登録に特化して利用、あくまで認証は外部キーを使うという整理になっていそうですね。

Sign In with AppleとのID連携現状のまとめ&Azure AD B2C連携

こんにちは、富士榮です。

WWDC'19でSign In with Appleが発表されてから皆Apple IDに夢中※1ですね。まぁ、アプリのレビューガイドラインの問題※2とか色々とありますが、日本人は不思議とiPhoneが大好きなので下手したらGoogleアカウントより普及してるのかもしれません。（パスワードを覚えているかどうかは別でしょうけど）

※1.今日（6/9）時点で私が把握しているSign In with Apple関係の記事

• Okta公式（おそらく一番早かったかも）
• https://developer.okta.com/blog/2019/06/04/what-the-heck-is-sign-in-with-apple
• ASP.NET CoreでのID連携方法
• https://www.scottbrady91.com/OpenID-Connect/Implementing-Sign-In-with-Apple-in-ASPNET-Core
• Auth0公式
• https://auth0.com/blog/implement-sign-in-with-apple-using-auth0-extensibility/
• Auth0公式の日本語訳（新Auth0 Ambassadorの@iMissYuさんが早速翻訳されました。素晴らしい！）
• https://qiita.com/iMissYu/items/ee8becd1e8fed8fb253c
• OAuth.jp
• https://oauth.jp/blog/2019/06/08/sign-in-with-apple-analysis/
• https://oauth.jp/blog/2019/06/12/sign-in-with-apple-analysis-2/
• IdM実験室（英語版）※手前味噌ですが・・・
• https://idmlab-e.eidentity.jp/2019/06/enable-sign-in-with-apple-on-azure-ad.html

※2.問題の概要
「サードパーティログイン採用のアプリはSign In with Appleを使うことを義務付ける」というレビューガイドラインが出たこと。Apple曰く、Relyingパーティに一切の個人情報を提供せずに認証だけを行うことができるためプライバシーに考慮している、という言いっぷりですが、逆にAppleが誰がどのアプリにログインしているかを把握するってこと？という気持ち悪い感じになっています。また、アプリ開発者はSign In with Appleを実装しなきゃダメ、という変な強権発動も流石Apple、という感じです。（個人の感想）

とは言え、Sign In with Appleが世の中に出てきたのでとりあえず色々とつないでみたくなります。私もAzure AD B2CとAuth0にはとりあえず繋いでみました。

というわけで、今回はAzure AD B2Cとのつなぎ方を解説します。
（先に書いた英語版のblogの日本語訳です）

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
WWDC'19でアップルが「Sign In with Apple」という機能を公表しました。このポストではこの新しい機能をどうやってAzure AD B2Cで使うかを説明したいと思います。もちろん、この機能をIdentity Experience Framework（カスタムポリシー）を使って構成することもできますが、今回はビルトインポリシーのOpenID Connect IdP連携の機能（Preview）を使って構成します。

最初にどのような動きになるのかビデオに撮ってみました。

前提事項

• アップル開発者アカウント（最低1年のサブスクリプション契約が必要）
• Azure Active Directory B2Cのテナント
• Azure WebApps等のWebホスティングサービス（Metadataのアップロード用）

アップル開発者コンソールでクライアントを構成する

「Sign In with Apple」はOAuth/OpenID Connect的な仕組みを採用しています（完全にプロトコルに準拠している訳ではなさそうですが）。そのため、それらのプロトコルに慣れ親しんでいる方であれば、実装するのはそれほど難しい話ではありません。

アップル管理者コンソールでOAuth/OIDCのクライアントを作成することが出来ます。手順については先に紹介したOktaのブログを参考にしました。とても良いブログだと思います。
https://developer.okta.com/blog/2019/06/04/what-the-heck-is-sign-in-with-apple

構成するための手順は以下の通りです。

1. Sign In with Appleを有効にしてApp Idを登録する
2. Service Idを登録する（これがclient_idとして使われます）
• ドメインの所有権を確認する
• redirect_uriを構成する
3. Sign In with Appleで利用する鍵を登録する
4. 登録した鍵をダウンロードして署名付きJWTを作る（これがclient_secretとして使われます）

Azure AD B2C上のIdentity Providerを構成する

Azure AD B2CでIdentity Providerを構成する前に、Apple Idに関するディスカバリ・ドキュメント（metadata）を作っておく必要があります。なぜなら、Appleは現在のところmetadata（/.well-known/openid-configuration）を公開していないためです。

私はAzure WebApps上に作成したmetadataを公開しましたが、任意のWebサービスを使うことが可能です。

Azure AD B2CのビルトインのOpenID ConnectのIdPを構成する際、metadataには以下の情報を記載する必要があります。

• Issuer
• Authorization Endpoint
• Token Endpoint
• Jwks Endpoint

また、metadataを公開するURIは./well-known/openid-configurationで終わっている必要があります。

こちらが作成したmetadataです。

さて、これでAzure AD B2Cのコンソールからビルトインポリシーを構成する準備が整いました。

新しいIdentity Providerを追加する。

OpenID Connect(preview)を選択する

metadata uri、client_id、client_secretを設定する。

sub属性を必須とされている属性へマッピングします。現状、Appleは名前やメールアドレスをid_tokenの中に含めて返してこないのでsub（pairwiseな値）しか使えません。

作成したIdPを利用する様にUser Flow(ポリシー)を構成する

Azure AD B2Cのコンソールでの最後のステップはUser Flowを構成することです。今回はSign In and Sign Up(v2)のポリシーテンプレートでApple IdPを使う様にフローを構成しました。

アプリケーションへ渡すための属性フローを構成します。

これで設定はおしまいです。

Azure AD B2Cに登録したアプリケーションから作成したポリシーを指定してID連携をすればApple Idでのログインが出来るようになっているはずです。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

と、言うことでまずはAzure AD B2Cでの構成方法を紹介しましたが、Auth0など他のものへの組込みについても解説できればと思います。（既に他の方も紹介されていますが）