こんにちは、富士榮です。
イベント続きでほぼ毎日プレゼンしている気がしますが、ストレスが溜まるので現実逃避です。
Auth0が生成AI向けの認証・認可に関するサイトをオープンしました。
まぁ、もともとOpenAIの認証はAuth0だったこともあり、この分野は以前から取り組んできていたんだと思います。
生成AIの認証・認可といっても単純にチャットボットへのログインだけでは面白くないわけで、ユーザの代わりにAPIを読んだり、RAGの認証をしたり、ユーザの確認を非同期で行ったり、とやることはたくさんあります。
この辺りをAuth0 Labでパッケージングしたサンプルを公開している、ということですね。
Auth0 Labのアカウントで先ほどのサイトのデモを試すと、ChatGPTもどきのアプリケーションが動きます。
なお、このソースコードはこちらのgithubレポジトリで公開されているので、自分のローカル環境でも試すことができます。
https://github.com/auth0-lab/market0
こういうフロントエンドとAPI管理周りは生成AIのエンジンとは独立したレイヤですが、自前で作るのは面倒な領域なのでこういうものがあると便利ですね。
こんにちは、富士榮です。
そういえばAuth0（Okta CIC）の管理画面へのログインにパスキーなどが使えるので使ってみたいと思います。
ちなみにちょっとだけ癖があります。簡単に書くと、
という感じです。最初からplatform認証器が登録できればいいのに。ちょっと実装が古いのかな。
さて、始める前に基本的な話を。IDaaSを使ってID基盤を構築するときに忘れてはいけないのはIDaaS自体の認証強化とアクセス制限です。
こんにちは、富士榮です。
皆さんIDトークンなどのJWT（JSON Web Token）の中身を確認するのに何を使っていますか？
私はOkta（Auth0）が提供しているhttps://jwt.ioやMicrosoftが提供しているhttps://jwt.msをよく使うのですが、いちいちブラウザを立ち上げるのが面倒な場合もありますよね。
もちろんjwt-cliを使ってコマンドラインで見るのもいいのですが、もうちょっとUIも凝ったものも欲しいよね、というVZ Editorが忘れられない人たちもこの界隈にはいるはずです。
ということで今回紹介するのはjwt.ioと同じくOkta（Auth0）が提供するjwt-uiです。
早速導入してみます。（私はMac環境ですが、Windowsでも使えるみたいです）
brewでインストールするようです。
brew tap jwt-rs/jwt-ui brew install jwt-ui
これだけです。
jwtui
これだけです。立ち上がりました。
-S, --secret <SECRET> Secret for validating the JWT. Can be text, file path (beginning with @) or base64 encoded string (beginning with b64:) [default: ]-s, --stdout Print to STDOUT instead of starting the CLI in TUI mode-n, --no-verify Do not validate the signature of the JWT when printing to STDOUT.-j, --json Format STDOUT as JSON-t, --tick-rate <TICK_RATE> Set the tick rate (milliseconds): the lower the number the higher the FPS. Must be less than 1000 [default: 250]-h, --help Print help-V, --version Print versionこんにちは、富士榮です。
OpenID Connectってシンプルなプロトコルだと思いますが、やっぱりOpenID Providerの気持ちにならないと本当のところはわからないよね、ということで「OpenID Providerを作る」シリーズ（デ⚫︎ゴ⚫︎ティーニ風）でもやってみようかと思います。
超絶ベーシックなところまでは前回・前々回のポストを踏まえて2時間くらいで作ってみたのでまずはこちらを解説しつつ実装を一緒に育てていきたいな、と考えています。
とりあえず作ったところまではこちらのレポジトリで公開しています。（前回のポストからの追加部分としては認可コードをJWEにしたところくらいです。詳しくはReadmeを見てください）
https://github.com/fujie/oidc-study-op
ということで、中身は次回から解説しますが現状の実装で何ができるのかの確認を兼ねてOpenID Connectの通信が実際にどうなっているのかを、Azure AD B2Cを使って確認してみようと思います。結構Azure AD B2CとかAuth0を触るときにサービス側が外部IdPにどういう期待をしているのかを知るためにこれまでも簡易IdPを作って通信トレースをとったりしていたのですが、この辺りの試行錯誤がOpenID Connectそのものを知ることにつながりますし、Azure AD B2CやAuth0などのIDaaSについての知識も深められて一石二鳥です。
早速Azure AD B2Cに作ったOpenID ProviderをIDプロバイダとして読み込ませてみます。作ったOpenID Providerはローカルで動かしていますのでngrokを使ってインターネットからアクセスできる様にしています。
ちなみにAzure AD B2Cに限らずMicrosoftのID基盤はresponse_modeとしてform_postをデフォルトにしているのですが、そんなものは作っていないのでqueryに変更してあげる必要があります。
free版のngrokを使っているのでngrokを止めてしまうとURLが変更されてしまうので注意が必要です。（もし止めてしまったら一度IDプロバイダを消して再作成する必要があります）
なお、ngrokを使う利点としてインスペクションができることです。（http://127.0.0.1:4040をブラウザで開くと通信内容がトレースできます）
Azure AD B2CでIDプロバイダの設定をして保存を行うとDiscoveryとjwks_uriへのアクセスがあります。
SAML 2.0 core仕様
https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf
こんな感じのリクエストになります。
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"ForceAuthn="false"ID="a133c62aafc8dcee7a69481de5af763c4ee370494"IssueInstant="2024-01-03T03:28:40Z"Destination="https://idp.example.jp/sso/login"AssertionConsumerServiceURL="https://sp.example.com/acs"ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"Version="2.0"><saml:Issuer>https://sp.example.com/sp</saml:Issuer><saml:Subject><saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">test@example.jp</saml:NameID></saml:Subject></samlp:AuthnRequest>
HTTP/1.1 302 FoundLocation: https://server.example.com/authorize?response_type=code&scope=openid%20profile%20email&client_id=s6BhdRkqt3&state=af0ifjsldkj&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb&login_hint=test@example.jp
こんにちは、富士榮です。
2023年も終盤に近づいてきたということで、今年もDigital Identity技術勉強会 #iddance Advent Calendar 2023に参加しています。
今回のネタはWorldcoinで話題のWorld IDを探っていきたいと思います。
ということでこんな内容でお届けします。
なお、お約束ですが本記事ではWorldcoinを含む特定の仮想通貨の購入や投資などを推奨するものではありません。あくまでDigital Identity関連技術の観点からWorldcoin/IDを見ていきたいと思います。
Worldcoin is an open-source protocol, supported by a global community of developers, individuals, economists and technologists committed to expanding participation in, and access to, the global economy. The Worldcoin Foundation is the steward, and will support and grow the Worldcoin community until it becomes self-sufficient. Tools for Humanity helped launch Worldcoin, and currently serve as advisors to the Foundation and operators of the World App.（原文）
ワールドコインはオープンソースのプロトコルであり、開発者、個人、経済学者、技術者からなるグローバルコミュニティによって支えられている。Worldcoin財団はスチュワードであり、Worldcoinコミュニティが自立するまでサポートし、成長させる。Tools for Humanityはワールドコインの立ち上げを支援し、現在は財団のアドバイザーとワールドアプリの運営者を務めている。（Deeplで機械翻訳）
Worldcoin was founded with the mission of creating a globally-inclusive identity and financial network, owned by the majority of humanity. If successful, Worldcoin could considerably increase economic opportunity, scale a reliable solution for distinguishing humans from AI online while preserving privacy, enable global democratic processes, and show a potential path to AI-funded UBI.（原文）
Worldcoinは、人類の大多数が所有する、グローバルに包括的なアイデンティティと金融ネットワークを構築することを使命として設立された。成功すれば、ワールドコインは経済機会を大幅に拡大し、プライバシーを守りながらオンライン上で人間とAIを区別するための信頼できるソリューションを拡大し、グローバルな民主的プロセスを可能にし、AIが資金を提供するUBIへの潜在的な道を示すことができる。(Deeplで機械翻訳）
要するに金融包摂の文脈で設立されたデジタルアイデンティティと金融ネットワークで、UBI（ユニバーサル・ベーシック・インカム）を実現することも一つのゴールとして定めている様です。
また、同時にWorldcoinを構成する要素についても以下のように説明が記載されています。
Worldcoin consists of a privacy-preserving digital identity network (World ID) built on proof of personhood and, where laws allow, a digital currency (WLD). Every human is eligible for a share of WLD simply for being human. World ID and WLD are currently complemented by World App, the first frontend to World ID and the Worldcoin Protocol, developed by the contributor team at Tools for Humanity (TFH).（原文）
ワールドコインは、個人であることの証明の上に構築されたプライバシーを保護するデジタルIDネットワーク（ワールドID）と、法律が認めるデジタル通貨（WLD）で構成されている。すべての人間は、人間であるというだけでWLDの分け前を得る資格がある。World IDとWLDは現在、Tools for Humanity (TFH)の貢献者チームによって開発された、World IDとWorldcoinプロトコルの最初のフロントエンドであるWorld Appによって補完されている。（Deeplで機械翻訳）
なるほど、Worldcoinのサイトのトップに記載されていたWorld ID、WLD、World Appはそれぞれ以下のような関係性だということがわかります。（トップページからリンクされるそれぞれのページの解説文からも補完）
もちろんこの状態でもWorld IDは作成されているのですが、World IDのもう一つの特徴は本当に人（Human）であることをOrbというデバイスを使って確認（物理的にOrbが置いてある場所まで行って対面で確認を行う）を行うことにあります。
まだID確認を行なっていない状態だとアプリの上部にVerify your World IDというリンクが表示されるのでタップすると近所に存在するOrbの場所が表示されますので、場所によっては予約をした上で現地を訪問して存在確認を行います。なお、この際に虹彩登録を行う必要があることから謎のシステムやデバイスに生体情報を提供するのはどうなのか？という議論も存在します。確かに私も渋谷の指定の場所へ行ってOrbでID確認をしてきましたが、かなりカジュアルな感じで登録ができてしまうので、偽Orbを作って生体情報だけを搾取する人たちが出てきても不思議ではありません（Orbを操作してくれる人も、Orbそのものについても登録しようとしている人から見て正当性を確認する手段がない）。この辺りは今後の課題なんだと思います。
なお、ID確認時には法的なアイデンティティ・ドキュメント（免許証などの身分証明書）の提示は求められないので、この辺りは金融包摂のため、という考え方がベースにあるのだと思います。ただ、一人のユーザが複数のWorld IDを取得できないようにするための虹彩情報の突合・重複確認がどこまで本当に実施されているのか？などはよくわかりません。
こんな感じのデバイスが置いてあるのでアプリのQRを読み込ませた後で虹彩登録を行います。登録自体は5分もかからずサクッと終わります。
なお、このID確認を行わないとベーシック・インカムとなるWLDを受け取ったり取引することができません。ちなみにWorld Appをインストールすると定期的（週一回くらい？）にGrantといってベーシック・インカムとしての3〜10程度のWLDが付与されます。現時点で1WLDは日本円で368〜9円程度なので、隔週で1,000円もらえる感じです。実際に利用する際は暗号資産取引所などで日本円へ換金することもできるんじゃないかと思います。（やったことありませんが）※追記：12/18の朝にみたら爆上がりしてました。624円とかになってました。
いずれにしても確認が終わるとVerifiedとして記録がされます。
さて、デジタルIDの話なので、あまり仮想通貨の話に行っても仕方がないのでWorld IDの使い方の話をしたいと思います。
非常にざっくりいうと、World IDもOpenID Connectに対応したIdentity Providerとしての機能を持っています。
開発者ポータルへアクセスし、サインアップすると一般のIdentity Providerと同じようにクライアント登録などができる仕組みが提供されています。
ちなみにAuth0（Okta CIC）ではすでにマーケットプレイスにSign in with Worldcoinの機能が提供されていますので、クライアントID/シークレットの登録とRedirectURIを設定すると簡単にWorld IDによるサインインが実装できます。
開発者ポータルでClient ID/Secret/RedirectURIの設定を行います。
簡単なRelying Partyを書いて実際のid_tokenの中身などを確認していきましょう。細かいコードは省略しますが、結果的にこんなid_tokenが返ってきます。
"https://id.worldcoin.org/beta": {
"likely_human": "strong",
"credential_type": "orb"
},
"https://id.worldcoin.org/v1": {
"verification_level": "orb"
},
ちなみに、Orbで確認を行なっていないWorld IDでもアクセスしてみるとverification_levelがdeviceとなっています。
"https://id.worldcoin.org/beta": {
"likely_human": "weak",
"credential_type": "device"
},
"https://id.worldcoin.org/v1": {
"verification_level": "device"
},
ところで、Auth0でも簡単なRelying Partyでも実装できたので、ついでにAzure AD B2Cでも実装してみようと思います。Discoveryもサポートしているし、openid-configurationを見るといつもの鬼門のresponse_mode=form_postもサポートしているようなので試してみます。
こんな感じでIDプロバイダーを設定します。
ところが、response_modeをform_postにするとWorld IDのAuthorizationエンドポイントでWorld Appでサインインしたところjsのエラーが出て止まってしまいます。どうもCSPの設定がうまくできていないみたいですね。。。
結果、
expect: '100-continue'
が犯人でした。
PostmanでもexceptヘッダをつけるとWorld IDのTokenエンドポイントがエラーを出しました。どうやらContent-Lengthの事前通知には対応していないようです。
とはいえ、APIクライアントとなるAzure AD B2C側のリクエストをここまで細かいレベルで調整するのはカスタムポリシーを使っても無理っぽいので、現時点では諦めます。（どうしても実装する場合はTokenエンドポイントとの間にゲートウェイモジュールを立ててProxyさせる形になると思います）
投稿
すべてのコメント
