ritouです。 タイトルに全部書きましたが、Xでharuyamaさんが書かれていたものです。 (広義の公開鍵暗号の)電子署名の文脈においては公開鍵/秘密鍵と言わないで署名鍵/検証鍵などと言ったほうがいいのではないかな— HARUYAMA Seigo (@haruyama) 2024年5月19日 よくある誤解 最近、公開鍵暗号方式がデジタル署名文脈で使われているユースケースに触れる機会が増えてきました。 自分の守備範囲でいうと OpenID ConnectのIDToken パスキーのAttestation/Assertion 雰囲気で使われているJWT認証() あたりでしょうか。 もちろん暗号化/復号のユースケースもあるにはあるのですが、自分の観測範囲ではデジタル署名文脈の方が圧倒的に多く使われています。 このあたりを解説しようとする記事において、誤解というか誤った認識をされがちなのが、

おはようございます 自称パスキー👮‍♂です。 様々なサービスでパスキー対応が進む中で、今回は特定機能の保護を目的とした導入とユーザーへの影響について取り上げます。 きっかけ ここ最近、🚔パスキーに関するパトロール🚔をしている中で、メルカリのパスキー導入についてこんなTweetを見つけました。 まずは１つ目です。 機種変更をしたら、メルカリのビットコインで取り引きできなくなってしまった。 ヘルプとかみて、認証情報を追加するとよさげなことが書いてあったので、試して見たけど、パスキーがないといわれて、登録することができない。つんだ。 事務局に問い合わせ中。#メルカリ #ビットコイン #パスキー pic.twitter.com/NoEKo8Hn5l— よっしー🖊 (@GateYossi) 2023年6月26日 新しいパスキーを追加しようと思ったがパスキーがない。 事務局で認証情報をクリアし

こんにちは、ritouです。 β公開から少し時間が経ってしまいましたが、1Passwordのパスキー対応について確認して整理しました。 www.publickey1.jp これまでAppleのiCloud KeychainやAndroidのGoogleパスワードマネージャーなどが プロバイダとしてのパスキーのサポートをしてきた中で、1Passwordが同様の対応をすることでクロスプラットフォームなパスキー利用環境が整うのか？と注目が集まっています。 個人的に1Passwordを活用しているので、使い勝手を見てみました。 環境は Chrome バージョン: 114.0.5735.133 @ macOS です。 1Passwordのβ版の拡張機能を有効にすることで動作確認ができます。 Relying Partyにはwebauthn.ioを利用します。 webauthn.io パスキーの生成/登

おはようございます、ritouです。 何の話？ 最近のユーザー認証を取り巻く状況について、次の2つの事例の共通点を考えましょう Passkey(FIDOアライアンスが言ってるMulti-Device FIDO Credentialsの方)はFIDOクレデンシャルがApple/Google/MSといったプラットフォーム(など)のアカウントに紐づけられる仕組み Google Authenticator のクレデンシャル管理がデバイス単位からGoogleアカウントに紐づくデバイス間で同期されるように変わる これらは "クレデンシャル" と呼ばれる、秘密鍵やパスワードなどの "認証のための情報" をデバイス単位ではなくプラットフォームアカウント単位に保存/管理するというお話です。 そのおかげで、新しいデバイスを使い始める際にこれまで利用してきたサービスに対して色々と設定しなおすことなく、Apple

ritouです。 "Digital Identity技術勉強会 #iddance Advent Calendar 2022" 13日目の記事です。 qiita.com 現状、Digital Identityを専門とするような開発者がいないような場合に新規サービスを立ち上げようと思ったら、Auth0やFirebase AuthenticationのようないわゆるIDaaSを利用するのも選択肢として上がるでしょう。 いわゆるID基盤的なものを0から設計、実装できるような 俺の考える最強の...みたいなの を既に見つけてる感じの人からすると「ちょっと違う」「凝ったことやろうとすると機能というか自由度が足りない」「帯に短し襷に長し」みたいな意見が出ることもありますが、現状だけではなくDigital Identity分野の今後のトレンドを追いつつ機能追加していくみたいな長い目で見た時にはそれなりに有

ritouです。 いよいよドコモさんもパスキー対応が始まりましたね！いや、これを書いている時点ではまだです。 k-tai.watch.impress.co.jp それよりも、今回はマネーフォワード IDのパスキー対応に注目します。 corp.moneyforward.com (4/5追記) マネーフォワード側からも解説記事が出ていました。この記事で言いたいことが全部書いてあります。 moneyforward-dev.jp ブラウザのパスワードマネージャー機能を利用したパスワード認証のUX パスキー対応に触れる前に、マネーフォワードIDのパスワード認証のUXから見ていきましょう。 マネーフォワードの「メールアドレスでログイン」のフローを何も考えずに使うと、最初にメールアドレスを入れてからパスワード入力を求めるUXになっています。 このようなUXでブラウザのパスワードマネージャーの機能を使う場

ritouです。 idcon の Yahoo! JAPAN の人の資料と動画を見たメモです。 www.docswell.com youtu.be 2画面のログインUX p5 2画面か一回でやるかの話は、個人的にこだわっているスキャンの話もありますね。 Y!JはFederation(RP側)をやっていませんが、マネフォのようにパスワード認証/FederationがあるところにWebAuthnを追加する場合にどうすべきか、みたいなのは別途どこかで整理したい気がしています。 推測 Platform Authenticator だけはなく YubikeyとかのRoaming Authenticatorに対応してる場合、リセットした場合も同じことが起こりそう。 そもそもFIDOはブラウザ - 認証器と多段の処理になっているのでブラウザレイヤーでの完全なコントロールってのも難しそう。 例えば、Andr

おはようございます、ritouです。 先日のWWDC2021の "Move beyond passwords" というセッションにて発表された "Passkeys in iCloud Keychain" という仕組みについてどんなものかを紹介します。 developer.apple.com WebAuthn 数年前からパスワード認証を置き換えると言われ続けている認証技術の一つである "WebAuthn" (やFIDO)という技術をご存知でしょうか。(ご存知ない方は "WebAuthn builderscon" "WebAuthn droidkaigi" などで検索してみましょう) 今回の話をするにあたって、WebAuthnがどんなものかをある程度理解しておく必要があります。 公開鍵暗号の仕組みを利用 パスワード認証のようにユーザーとログイン対象のWebアプリケーションがパスワードを共有する

おはようございます。ritou です。 5月下旬ぐらいにチーム内勉強会としてJSON Web Token(JWT)についてわいわいやりました。 その際に作成した資料に簡単な説明を添えつつ紹介します。 このブログではJWTについて色々と記事を書いてきましたが、その範囲を超えるものではありません。 ちょっとだけ長いですが、ちょっとだけです。お付き合いください。それでは始めましょう。 JSON Web Token boot camp 2020 今回の勉強会では、JWTについて概要、仕様紹介という基本的なところから、業務で使っていくにあたって気をつけるべき点といったあたりまでカバーできると良いなと思っています。 JSON Web Token 概要 まずは概要から紹介していきます。 JSON Web Tokenの定義とはということで、RFC7519のAbstractの文章を引用します。 JSON W

おはようございます、ritouです。 (⚠️認可イベントの識別子のあたり、ちょっと見直しました！最初に見ていただいた方はもう一回どうぞ！) 前回、ハイブリッド型と呼ばれる OAuth 2.0 のトークン実装について書きました。 ritou.hatenablog.com その続きとして JWT(JWS) + RDBでできる実装例を紹介します。 理解するにはそれなりの OAuth 2.0 に関する知識が必要になるかもしれませんが、よかったら参考にしてみてください。 何を考えたのか OAuth 2.0のRefresh Token, Access Tokenを考えます。 要件から整理しましょう。 要件 結構ありますが、最低限の OAuth 2.0 の Authorization Server を実装しようと思ったらこれぐらいはやらないといけないでしょう。 RFC6750 で定義されている Bear

おはようございます、ritou です。 qiita.com これの初日です。 なんの話か 皆さんは今まで、こんな記事を目にしたことがありませんか？ Cookie vs JWT 認証に JWT を利用するのってどうなの？ JWT をセッション管理に使うべきではない！ リンク貼るのは省略しますが、年に何度か見かける記事です。 個人的にこの話題の原点は最近 IDaaS(Identity as a Service) として注目を集めている Auth0 が Cookie vs Token とか言う比較記事を書いたことだと思っていますが、今探したところ記事は削除されたのか最近の記事にリダイレクトされてるようなのでもうよくわからん。 なのでそれはおいといて、この話題を扱う記事は クライアントでのセッション管理 : HTTP Cookie vs WebStorage(LocalStorage / Sess

どーも、ritouです。 世の中みんながこの話題に夢中かと思います(大げさ)。 github.blog GitHubは以前から2要素認証の方式としてセキュリティキーをサポートしてきました。2015年ですって。 github.blog 今回、その実装がWebAuthnに変更になったということです。 forest.watch.impress.co.jp 将来的には“Windows Hello”や“Touch ID”などもサポートされるという。 Windows HelloやmacOSのChromeなどを用いたTouch IDが利用可能になるのは、将来の話ではありません。もう対応しています。 www.publickey1.jp この記事はパスワードレスを実現したかのような書きっぷり。 WebAuthnはパスワードレスを実現するための仕組みだが、今回のGitHubの対応は用途を2要素目の認証方法に限

おはようございます、ritou です。 今日は日頃の情報収集方法の一つである Mike Jones氏のブログ記事に書いてあったドラフト仕様のご紹介です。 self-issued.info The specification is still an early draft and undergoing active development, but I believe the approach shows a lot of promise and is likely to be adopted by the OAuth working group soon. まだDraft中のDraftな状態ですが、まいくたんの推し感が出ているのでざっと見ておきましょう。 OAuth2.0 DPoPとは？ tools.ietf.org This document describes a mechanism

おはようございます。ritou です。 builderscon tokyo 2018 にて WebAuthn のさわりの話をした時に、「OAuth / OpenID Connect」 との関係について質問がありました。 この質問に限った話ではありませんが、"認証のための技術" なんていうと、認証方式、認証状態のセッション管理、ID連携まで広範囲に渡るため、話が混乱してしまうものです。 ここでは OIDC で言うところの誰が WebAuthn で言う所の誰になるとどうなるのか、みたいな話を書きます。 前提 FIDO と Identity な標準化技術は "補完関係" 結構前ですが、もっと詳しい方が書いたものを紹介します。 https://www.jstage.jst.go.jp/article/itej/70/5/70_481/_pdf 上記FIDOの技術仕様は、認証の領域にのみ注力していま