おはようございます。 月曜です。 ritouです。 先週、こんな記事出てました。 Why you should stop using the OAuth implicit grant! もう Implicit grant 使ってくれるなよ 仕様策定中の OAuth 2.0 Security Best Current Practice(今はDraft9) で使用しないことを推奨している バンコクで開かれた今週のIETF meetingで決定された ということらしいです。 Implicit grantといえば Token Replace Attack や Covert Redirect など、OAuth 2.0の脆弱性を語る上で欠かせない唯一無二の存在であります。 www.atmarkit.co.jp 私の中では最初から非推奨ですが、公式にとなると気になりますね。 策定中のドキュメントではどう

おはようございます、ritouです。 今回は、一部で先週話題なりましたOAuth 2.0のImplicit Flowについてのエントリになります。 (2012/2/7 いろいろと修正しました。) 単なる OAuth 2.0 を認証に使うと、車が通れるほどのどでかいセキュリティー・ホールができる | @_Nat Zone Thread Safe: The problem with OAuth for Authentication. 今回は以下の内容について整理したいと思います。 OAuth 2.0のどの機能にセキュリティホールがあるのか 誰が攻撃者になれるのか 対策 OAuth 2.0 Implicit Flowとは OAuth 2.0ではサードパーティーアプリケーションが保護リソースへのアクセス権限を得るためのいくつかのフローが定義されています。 (仕様中ではFlowやGrant Type

こんばんは、ritou です。 パスキーの記事ばっかり書いてないでたまにはOAuthのことも取り上げましょう。 OAuthのAccess Tokenについて少し復習してみましょう。 OAuthのAccess Token ってJWTじゃないの？ これについては、我らが Auth屋さん がお話しする会みたいなので自分の方でもいくつか勝手に質問に答えた中にありました。 RFC 6749: The string is usually opaque to the client. RFC 9068: This specification defines a profile for issuing OAuth 2.0 access tokens in JSON Web Token (JWT) format. と言うようにATの形式は決められていないがJWTを使うためのプロファイルもある、と言うところ。

おはようございます ritou です。 久々に「解説付きスライド全公開」的なやつをやります。 先月、チーム内でID連携のための標準化仕様に関する勉強会(私が一方的に話す会)を行いました。 が、実際はだいぶグダグダになってしまい、これはその後色々付け足してるうちに別物になってしまった資料です。 内容としては、ID連携のための標準化仕様にどのようなものがあるかを知ってもらうための「入門編」のような立ち位置で作りました。 OpenID Connect(やSAMLのような) ID連携のための標準化仕様を紹介しようと思うと、ついつい個別にシーケンスやリクエスト/レスポンスの説明を始めがちですが、初学者が気になるのはそんな細けぇことではないでしょう。 まずは「この仕様で何ができるようになるのだろう」「この仕様では何を実現したいんだろう」と言うところから理解していくのが良いのではないでしょうか。 そこで

ritouです。 OAuth 2.0 / OIDC を触って「そろそろ完全に理解したって言っちゃおうかな」なんて思った時に出会ってしまうのが Hybrid Flow です。 某書籍のレビュー時に Hybrod Flow について著者といくつかやりとりをしたのですが、なんだかんだで結構ややこしいので私の考える向き合い方を書き残しておきます。 Hybrid Flow とは Authorization Code Flow(Grant) や Implicit Grant(Flow) に比べて、まず定義からよくわからないと言う声を多く聞きます。 仕様を紹介している記事ではこんな感じで書かれています。 Hybrid Flow Authorization Code といくつかのトークンが Authorization Endpoint から返され, その他のトークンが Token Endpoint から返

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

こんばんは。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

おはようございます 自称パスキー👮‍♂です。 様々なサービスでパスキー対応が進む中で、今回は特定機能の保護を目的とした導入とユーザーへの影響について取り上げます。 きっかけ ここ最近、🚔パスキーに関するパトロール🚔をしている中で、メルカリのパスキー導入についてこんな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です。 いよいよドコモさんもパスキー対応が始まりましたね！いや、これを書いている時点ではまだです。 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です。 Google I/O の "A path to a world without passwords" っていう発表、ご覧になりましたか？ www.youtube.com FIDO, WebOTP, FedCM...いいネタ揃ってますね！今回はFIDOの話をしましょう。 パスワード認証はもう終わり！時代はパスワードレス認証ですよと言い続けてはや数年経ちましたが、最近こんなプレスリリースが出ていました。 prtimes.jp すべての人にとってウェブをより安全で使いやすいものにするための共同の取り組みとして、Apple、Google、Microsoftは本日、FIDOアライアンスとWorld Wide Web Consortium（以下、W3C）が策定した共通のパスワードレス認証のサポートを拡大する計画を発表しました。 何やら大ごと感ありますが、3行でまと