デジタル署名文脈での公開鍵暗号方式の誤解を避けるため、署名鍵/検証鍵という表現を使うというお話 - r-weblife
ritouです。 タイトルに全部書きましたが、Xでharuyamaさんが書かれていたものです。 (広義の公開鍵暗号の)電子署名の文脈においては公開鍵/秘密鍵と言わないで署名鍵/検証鍵などと言ったほうがいいのではないかな— HARUYAMA Seigo (@haruyama) 2024年5月19日 よくある誤解 最近、公開鍵暗号方式がデジタル署名文脈で使われているユースケースに触れる機会が増えてきました。 自分の守備範囲でいうと OpenID ConnectのIDToken パスキーのAttestation/Assertion 雰囲気で使われているJWT認証() あたりでしょうか。 もちろん暗号化/復号のユースケースもあるにはあるのですが、自分の観測範囲ではデジタル署名文脈の方が圧倒的に多く使われています。 このあたりを解説しようとする記事において、誤解というか誤った認識をされがちなのが、
PWA Night vol.57 ～認証・認可〜 にてパスキーの話をしました - r-weblife
ritou です。 これで話しました。 pwanight.connpass.com 発表資料と発表内容を公開します。 発表資料 speakerdeck.com 発表内容 台本チラ見しながら話したので実際にはこのとおりになってなかった部分もあります。 今日は、パスキーについて話します。 細かい自己紹介は省略します。 色々宣伝したいものがありますがブログに書きます。 今日の内容ですが、初めにパスキーの概要についてざっと触れます。 続いてWebアプリケーションにパスキーを導入するとなった場合にどこから手をつけるべきかというところに触れた後、一番の悩みどころになりそうなログインのUI/UXについて紹介します。 概要からいきましょう。 パスキーの紹介記事もたくさん出ているので要点だけまとめます。 パスキーとは「パスワードが不要な認証方式」であり、それを支える仕様はFIDOアライアンスとW3Cにより策
β公開された1Passwordのパスキー対応について調べてみた - r-weblife
こんにちは、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 パスキーの生成/登
プラットフォームアカウントに紐づけられたクレデンシャルを利用するユーザー認証について - r-weblife
おはようございます、ritouです。 何の話？ 最近のユーザー認証を取り巻く状況について、次の2つの事例の共通点を考えましょう Passkey(FIDOアライアンスが言ってるMulti-Device FIDO Credentialsの方)はFIDOクレデンシャルがApple/Google/MSといったプラットフォーム(など)のアカウントに紐づけられる仕組み Google Authenticator のクレデンシャル管理がデバイス単位からGoogleアカウントに紐づくデバイス間で同期されるように変わる これらは "クレデンシャル" と呼ばれる、秘密鍵やパスワードなどの "認証のための情報" をデバイス単位ではなくプラットフォームアカウント単位に保存/管理するというお話です。 そのおかげで、新しいデバイスを使い始める際にこれまで利用してきたサービスに対して色々と設定しなおすことなく、Apple
「使える人にだけ使わせる」 ~ マネーフォワード IDのログインUXから見るパスキー普及のポイント - r-weblife
ritouです。 いよいよドコモさんもパスキー対応が始まりましたね！いや、これを書いている時点ではまだです。 k-tai.watch.impress.co.jp それよりも、今回はマネーフォワード IDのパスキー対応に注目します。 corp.moneyforward.com (4/5追記) マネーフォワード側からも解説記事が出ていました。この記事で言いたいことが全部書いてあります。 moneyforward-dev.jp ブラウザのパスワードマネージャー機能を利用したパスワード認証のUX パスキー対応に触れる前に、マネーフォワードIDのパスワード認証のUXから見ていきましょう。 マネーフォワードの「メールアドレスでログイン」のフローを何も考えずに使うと、最初にメールアドレスを入れてからパスワード入力を求めるUXになっています。 このようなUXでブラウザのパスワードマネージャーの機能を使う場
JWT カテゴリーの記事一覧 - r-weblife
こんばんは、ritou です。 パスキーの記事ばっかり書いてないでたまにはOAuthのことも取り上げましょう。 OAuthのAccess Tokenについて少し復習してみましょう。 OAuthのAccess Token ってJWTじゃないの？ これについては、我らが Auth屋さん がお話しする会…
idcon29のY!Jの事例からログインフローにおけるWebAuthn対応の課題を考えた - r-weblife
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
ID連携の標準化仕様紹介とセキュアな実装のためのアプローチ ~ 2021 - r-weblife
おはようございます ritou です。 久々に「解説付きスライド全公開」的なやつをやります。 先月、チーム内でID連携のための標準化仕様に関する勉強会(私が一方的に話す会)を行いました。 が、実際はだいぶグダグダになってしまい、これはその後色々付け足してるうちに別物になってしまった資料です。 内容としては、ID連携のための標準化仕様にどのようなものがあるかを知ってもらうための「入門編」のような立ち位置で作りました。 OpenID Connect(やSAMLのような) ID連携のための標準化仕様を紹介しようと思うと、ついつい個別にシーケンスやリクエスト/レスポンスの説明を始めがちですが、初学者が気になるのはそんな細けぇことではないでしょう。 まずは「この仕様で何ができるようになるのだろう」「この仕様では何を実現したいんだろう」と言うところから理解していくのが良いのではないでしょうか。 そこで
Chrome 93で実装されたCross Device WebOTPフローを試してみた - r-weblife
おはようございます ritou です。 8月ですよ。お仕事の進捗大丈夫ですか？ 最近、Google方面からDecoupled AuthNの香りがしたので追ってみました。 何の話? この話です。 developer.chrome.com WebOTPとは? Webアプリケーションがモバイル端末でSMS経由のOTP認証をしようと思った時、画面に「認証コードを送信しました」なんて出た後にSMSを確認できるアプリを起動して確認してまたブラウザに...とかをやったことがある人は多いでしょう。 WebOTPとは、モバイル端末上のブラウザであればアプリの切り替えをせずにワンタップでSMSで受け取ったOTPの値を読み込んで検証リクエストに繋げられる、しかもSMSを発信したWebアプリを特定できるフォーマットになっていることでフィッシングサイトからはこのフローを使えなくするような仕組みのことです。 web.
OAuth認証とは何か?なぜダメなのか - 2020冬 - r-weblife
こんばんは。ritouです。 Digital Identity技術勉強会 #iddance Advent Calendar 2020 1日めの記事です。 qiita.com 初日なのでゆるふわな話をしましょう。 何の話か もうだいぶ前ですね。9月のお話です。こんなTweetを見かけました。 社内Slackにいる「OAuth認証」と書くと訂正してくれるbotが丁寧な解説をするようになっていた 認証(Authentication)と認可(Authorization)は間違えやすいわりにミスると甚大な被害をもたらしがちなので、常日頃から意識を高めていきたいですね pic.twitter.com/oVQxBgZcHS— greenspa (@greenspa) 2020年9月28日 このbotに対する思うところはもう良いです。 今回は、「OAuthの仕様に沿ってID連携を実装するいわゆる"OAut
OAuth 2.0/OIDCに入門した開発者が仕様沼に潜るための次のステップとは？ - r-weblife
お疲れ様です、ritou です。 OAuth 2.0やOIDCの入門書(?)を読み終えた開発者の方に、仕様を理解していくための次のステップは何があるかを聞かれました。 そもそもそんなこと言う人は クライアントを実装したい(しなければならない) 認可サーバーを実装したい(しなければならない) セキュリティエンジニアを名乗っていてこの分野を抑えときたい ただ単純に興味がある : そんな人いる？ とかそんな感じな気はしますが、基本的なフローを乗り越えた先に広がる仕様沼への潜り方に戸惑っておられるようでした。 そこで、いわゆる RFC6749/6750/7636 あたりを完全に理解した開発者が山ほどある仕様にどう立ち向かっていくかを考えます。 仕様にも色々ある IETF の OAuth関連の仕様、いっぱいあります。密です。密です。みみみみみみみみ... tools.ietf.org 去年に一回まと
Webアプリケーションのセッション管理にJWT導入を検討する際の考え方 - r-weblife
おはようございます、ritou です。 qiita.com これの初日です。 なんの話か 皆さんは今まで、こんな記事を目にしたことがありませんか？ Cookie vs JWT 認証に JWT を利用するのってどうなの？ JWT をセッション管理に使うべきではない！ リンク貼るのは省略しますが、年に何度か見かける記事です。 個人的にこの話題の原点は最近 IDaaS(Identity as a Service) として注目を集めている Auth0 が Cookie vs Token とか言う比較記事を書いたことだと思っていますが、今探したところ記事は削除されたのか最近の記事にリダイレクトされてるようなのでもうよくわからん。 なのでそれはおいといて、この話題を扱う記事は クライアントでのセッション管理 : HTTP Cookie vs WebStorage(LocalStorage / Sess
GitHubの2要素認証がWebAuthnに対応したらしいので触ってみた - r-weblife
どーも、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要素目の認証方法に限
SPAなClientがトークンを安全に扱えるかもしれない拡張仕様「OAuth2.0 DPoP」とは - r-weblife
おはようございます、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
RFC7636として発行されたOAuth PKCEとは - r-weblife
おひさしぶりです、ritouです。 今日は家で風邪治してましたが、TLに流れてきた次世代なんちゃらの話題に乗っかって、ざっくりとした仕様紹介です。 ベンダー個別のパスワード管理には課税せよ！？ 次世代Webカンファレンス『identity』 #nextwebconf #nextwebconf407 - Togetter OAuth PKCEがRFC7636として発行されました。 | @_Nat Zone RFC 7636 - Proof Key for Code Exchange by OAuth Public Clients 一言でいうと この規格はOAuth 2.0 [RFC6749]のPublic Client の Code Interception Attack 脆弱性に対応するもので、ephemeral keyを生成して、これを使ったProof of Possession of
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
