はてなブックマーク

ritou です。 もう23日ですが、Digital Identity技術勉強会 #iddance Advent Calendar 2024 10日目の記事です。 最近パスキー関連の記事などを書いている中、いわゆるログイン機能について様々な捉え方があることを改めて感じています。 ユーザー目線ではなかなか難しいことはありつつも、開発者目線でログイン機能を設計する際には共通認識を持つことが重要です。今回はアカウントリカバリー付きのログインフローを設計する際の考え方を整理してみます。 キーワード この説明におけるキーワードとなる処理は次の3つです。 当人認証: いわゆる認証処理。サービス登録済みのユーザーを識別し、検証する。 パスワード認証、パスキー認証、メール/SMS OTP、TOTPなど個々の認証方式で実現できる部分。ソーシャルログインも同様。 身元確認: ユーザーが主張した属性情報の検証。

ritou です。 みんなが待っていたデジタル認証アプリの情報が公開されました。 開発者向けのガイドライン、APIリファレンスなどのドキュメントも公開されています。 今回は開発者視点でどんな作りになっていて、利用するために理解が必要となる標準化仕様はどのあたりなのかを取り上げます。ちょっとOIDCのRPやOAuthのClient実装経験のある開発者向け、ぐらいの内容です。 概要 公開された情報からすると デジタル認証アプリサービス(アプリ+バックエンド)はマイナンバーカードを用いた当人認証を実施 現在は都度マイナンバーカードを利用する必要がありますが、いずれはスマホに保存されたカード情報を使ってもっと楽になりそう ID連携のIdentityプロバイダとして認証イベント情報、基本4情報といった属性情報を民間/行政サービスに提供 民間/行政サービスは認証イベント情報に含まれるユーザー識別子を利

(4/14 表記揺れなどのコメントいただいたので、少し修正、追記しました。) ritouです。 私のタイムラインによく出てくる、この辺りの話っていつになってもしっくりこない人が多いと思います。 OAuth認証👮 : アプリケーションがユーザー情報取得を提供するAPIを叩いて受け取ったユーザー識別子を使って新規登録やログインさせてはいけない。OIDCのIDTokenを使え ユーザーIDが取得できればログインさせていいのではないか IDTokenはユーザーIDを含むJWTだが、どうしてこれは良いのか デジタル庁が進めるマイナンバーカードを用いた個人向け認証アプリケーション(以下、認証スーパーアプリ)の用途 マイナンバーカードを用いた本人確認は既にいくつかの民間サービスで使われているが、ログインに使えるとはどういう事なのか デジタル庁からは スマホ用電子証明書搭載サービス という物も出ているが

ritouです。 こちらの記事の続きです。 前回の記事の振り返り 3行でまとめると まずは単一アプリケーションのID管理について解像度を上げてみよう Webアプリケーションフレームワークを使って新規登録から退会までざっくり動作確認してから、色々いじったり調べてみるのが良いよ セキュリティ関連の機能とか、新規登録時の身元確認、ログイン方法を拡張してみよう といったところです。個人的にはこれは全エンジニア向けの研修であってもいいぐらいのものだと思います。 今回の内容 タイトルにある通り、複数のアプリケーションが関わる部分に入っていきましょう。 というか、OAuthとOIDCやりたいんですよね?え?SAML? まずはID連携のベーシックな部分に触れていきましょう。 プロトコルは混ざっちゃっていますが、順番としてはこんなのはどうでしょう。 OAuth 2.0のClientとしての機能を設計/実装す

ritou です。 これについての話です。 この辺りずっとやってると「認証認可について詳しくなりたいです!」「OIDCに興味があります!」みたいなところから「何をやればいいですか!?」みたいなことを聞かれたりします。(やりたいことやればいいじゃんと思いつつ) 昔は 年に一回ぐらいIdPを作りましょう なんて言っていた時期がありますが、まぁそう簡単にできるものでもありません。ふじえさんの記事をdisっているわけではないですが、OIDCのところから始めても他にやることが多すぎて結構つらいのです。 何から始めたら良いか 現状のおすすめとしては、 Webアプリケーションフレームワークを使って単一アプリケーションを動かして、既存コードを追ったり拡張できるならやってみて色々細かい部分を理解するところから始めましょうというところです。 なんと、ひと昔前にQiitaに溢れたようなやり方ですが どのフレーム

パスキー対応 という記事を見ると フィッシング耐性があるパスワードレスな世界が来る! と期待を抱き、冷静に考えて パスワードが残ってるうちはリスクは残ってるしフィッシングにもやられるし何にもかわらねぇじゃねーか と遠い目をしてしまう皆さん、こんにちは。 ritou です。 いきなり一気に進むわけがないだろ。ということで、認証を必要とするサービスもユーザーも、パスキーにより理想的な状態となるまでには段階というものがあり、 大人の階段と同じで やるべきことがあります。そのあたりを理解することで、一喜一憂せずにやっていきましょう。 2つの段階 既存の認証方式に加えてパスキーによる認証が利用可能 : 過渡期ってやつでしょうか。イマココ パスキーのみが利用可能 : 我々が望んでいる世界や! あとはその前の なんもしてない段階 です。 そんなに新しい話でもないでしょう。 段階を進めるために必要な対応

こんばんは、ritouです。 タイトルの通り、お話をしてきました。 それではどうぞ。 動画 (2024年4月12日: 動画が公開されていたので追記しました) 内容 OIDF-Jでエバンジェリストをしています。ritouです。 今日はパスキーとID連携についてお話させていただきます。 この発表では次の3点について話します。 それぞれの特徴/特性 ID連携のIdP/RPそれぞれがパスキー認証をサポートすることで得られるもの 関連するOIDC/OAuth 2.0の仕様 まずはそれぞれの特徴、特性から見ていきます。 パスキー、具体的には「FIDOクレデンシャルを用いた認証方式」について、特徴を振り返ります。 まずは公開鍵暗号を利用すること、ブラウザなどの仲介によるフィッシング耐性による安全性です。 そして、利用者の確認としてローカル認証と呼ばれる画面ロック解除の仕組みを利用すること、各プラットフォー

ritou です。 Digital Identity技術勉強会 #iddance Advent Calendar 2022 1日目の記事です。 今日はこの話をします。 SAMLのIdP-initiated フロー/メソッド/SSO とか呼ばれているやつ 仕様だとこの辺りでしょうか? In addition to supporting the new SP-Initiated web SSO use cases, SAML v2 continues to support the IdP-initiated web SSO use cases originally supported by SAML v1. In an IdP-initiated use case, the identity provider is configured with specialized links that

ritou です。 少し前にパスキーとID連携の関係を考えるときにこういう観点があるよという話をしずかな方に書きました。 今回は、ログインに利用しようとした時のフローの中でここ似ているよね、こんな意図があるんだよっていう部分を取り上げます。 認証フローの似ている点 登場人物をUserAgent、RP、Authenticatorとして、あらゆるところを簡略化したシーケンスを用意しました。 ID連携、いわゆるソーシャルログインでは次のようになります。 登場人物をUserAgent、RP、IdPとするとこんな感じでしょう。 もちろん細かいところは違うわけですが、全体の流れは似ています。 WebAuthnのchallenge, OIDCのnonce, state 先ほどのシーケンス、たまたま似ていると言うよりも、これは認証フローにおける基本の流れであると意識しておきましょう。 パスキーやID連携の

ritouです。 Digital Identity技術勉強会 #iddance Advent Calendar 2023 シリーズ2 の記事です。 なんの話か 自分が関わっているサービスでは、パスキーによる認証をサポートするまでは、SMS/Email OTPによるユーザー認証のみを採用していました。 その頃から、"あるSMS番号やメールアドレスが登録済みかどうかを第3者に知らせない(自分の投稿では"ユーザーをスキャンさせない"と表現しています)" というポリシーを定めていました。昨年の会社のアドカレに書いた記事でそれに触れています。 今回は、パスキー対応するにありいくつかあるログインのUXパターンに "ユーザーのスキャン" という観点を入れた整理をします。 3つのログインUXパターン 最近、パスキーのログインUXにはいくつかのパターンがあって、特徴が異なるよというお話を勉強会でしました。

ritouです。 Digital Identity技術勉強会 #iddance Advent Calendar 2023 の 初日の記事です。 こちら、参加者を募集中です!気軽に参加してみてください!してくれよ!はよ! なんの話か ちょっと想定以上に反応をいただいたこちらの記事について、ちょっとだけ補足をしたいと思います。 なんの話か詳しく 自分のはてブのコメントをつけたポストにもたくさん反応いただきました。 実際、海外のサービスはメアドをキーにして参照してるところも多く これはサービスのDBのUserテーブルがemailをプライマリキーにしているという話ではありません(が、そう思われた方からDMが来ました)。 最初にパスワード認証やメールでリンクを送信して認証させる仕組みを実装している状態から、ソーシャルログインを実装しようとする際に "email" をキーにした参照をすることがあるんよ

ritouです。 某イベントのこの辺で出てくる質問に回答してみました。 Q. SAMLとの違い A. OAuthとは目的/用途が異なる。OIDCとの比較では、SAMLをモダンにしたのがOIDCという認識でおk。XML->JSON, XML Signature->JWTみたいな仕様の違いがある。あとはOIDCはSPAやモバイルアプリ、Verifiable Credentialsといった世の中の動向に追従して現在進行形で拡張仕様やプロファイル、ベストプラクティスの策定が進められている。 Q. 言葉の定義 A. 英語では決まっている。日本語に変換するときにおかしくなったり、IDaaSなどでOIDCをそのまま適用していない場合などで用語の混乱が起こりうる。 Q. 人間が介在しない認証フローではImplicit?非推奨? A. おそらくClientCredentialsの方が適している Q. Con

ritou です。 パスキーに関するTips始めました 今回の内容 Apple, Google, Microsoftがパスキーパスキー言い出した時、FIDOアライアンスがこんな動画を出していました。みたことある方もいらっしゃるかもしれません。 この後半で、Android端末のパスキーを用いてWindows PCのブラウザでサービスにログインして、その直後にWindows Helloでもパスキーを登録するっていう流れが説明されています。 同じように、Android端末のパスキーを用いてMacOSのSafariでサービスにログインして、その直後にiCloud Keychainでもパスキーを登録するっていう流れも説明されています。 今でこそ1Passwordとかでクロスプラットフォームのパスキー利用が実現できそうなものの、最初の頃の「え?プラットフォームを超えた同期はできないの?そりゃそうか」と

ritouです。 前回は、パスキーやパスワードマネージャーを使う時の認証要素について触れました。 今回は、 同じ要素の認証を重ねる意味 同一端末やパスワードマネージャーだけで完結するMFA あるアカウントに紐づけられて同期されるクレデンシャル管理 についての 基本的な整理 をします。 前回に続き、書いていることは無難な内容だと思います。 (長いので先に)まとめ 単一要素を重ねる意味について、要素の種類によっては有効な場合もある SYK を重ねるケースは決済などでまだ見られるが今後は淘汰されていくのでは? SYH の場合、管理デバイスを分離することで安全性を上げられる。ただし手間は増えるしフィッシング耐性は別途考慮する必要あり。 SYA を重ねる=単一SYAの精度を上げるのと同じ扱いになりそう(顔だけ、指紋だけ -> 顔 + 指紋など) 同一端末やパスワードマネージャー内で完結するMFAやプ

ritouです。 サービス、ブラウザ、OSそれぞれのパスキー対応が日々進んでいます。 その中で、パスキーを利用してみて認証要素についてふと考えてしまう人がいるでしょう。 パスキー簡単!けどこれ指紋認証だけ?弱くなってない? SMS OTPを2FAに設定し、パスワードマネージャーも使ってたから使い勝手はあまり変わらない。むしろSMS OTPがないぶんだけ弱くなった? この辺りについて整理します。 認証要素というと、次の3つです。 SYK: Something You Know. パスワード、PIN SYH: Something You Have. 認証アプリ、TOTP生成アプリ、バックアップコード、 SYA: Something You Are. 生体認証 前にこんな記事を書きました。 この内容を説明すると、「うん、わかってる」って人は多いです。 でも、実際に使ってみると心許なく感じたりする

ritou です。 XのTLを見ていたら、Amazonでの不正ログインについての投稿が目に入りました。 いざ被害にあってしまうと"2段階認証も意味ない"みたいな投稿をしてしまうほど、混乱してしまうものです。 混乱したり、不安になってしまったユーザーがサービスを退会してしまわないように、サービス側でできる仕組みを整理しておきましょう。 これまで何が起こったか、今どうなっているのかを確認できる仕組みを提要 これまでの啓蒙が実ったのか、被害にあって実感したユーザーが増えたからなのか、不正ログインが起こったらパスワードを変えるという意識は広まったようです。 2019年にQiitaに投稿しましたが、不正ログインが起こった際に必要なのはユーザーが正しく情報を知ることができる仕組みです。 何が起こったのかを知る : セキュリティイベントログ 今どうなっているかを知るしくみ : ログインセッションの管理

こんばんは、ritouです。 今回はこれを試してみます。 まずはパスキーを有効にします。 PCの画面だと右上のプロフィール画像をクリックするとワーっと出てくる中の "Feature preview" ですね。 "Passkeys" のところを選んで こう! (Enable) で、右に表示されている "Add a Passkey" を押してもこれ ただの画像なので何も起こらないですよ。 本物は "Settings" -> "Password and authentication" と進めばあります。 2FAで使っていたPasskeyの昇格 追加してみようと思うと、再認証が必要...わかります。 そういえば自分は2FAで既にHybrid Transportを使ってAndroidのPasskeyを利用していました。 とりあえずそっちで再認証を終わると... ・・・おや!? 2FA用のPasske

ritouです。 最近、SMS経由でOTPを送信する認証方式について色々言われています。 SMS Traffic Pumping Fraud Twitterもやられたというやーつ。 認証に限らず他の用途でもSMS送信を利用しているサービスにとっては頭の痛い問題。 SIMスワップ SIM再発行時の対面KYCのところを突破されたらどうしようもない感 SMSだけに頼っているサービスならSMSをやられたから被害に遭う、それはそうだが... この件は割とターゲットを絞って行われたお金持ち狙いの攻撃なのでは?とも思わなくない こういう事案が発生しているので、SMSを使ってどこまでできていいのかという話、やられたらどうするかの想定、リスク受容について見直すべきという意見はごもっともです。 もっと簡単にeSIMが発行できるところがあるみたいな話もありますし、今回の例では悪い人が対面で偽造免許持っていく手間

ritou です。 Digital Identity技術勉強会 #iddance Advent Calendar 2022 10日目の記事を代理で書きます。 今回は、APIを叩いて何がしを行うbotとかを作る際に必要になるアクセストークンの話をします。 世の中いろんなAPIが公開されてそれを組み合わせたピタゴラスイッチみたいな仕組みが実現できる時代でありますが、その際に利用されるアクセストークンについて、いくつか種類があります。 あるユーザーとして、その代わりとしてAPIを叩いてリソースアクセスを行うためのトークンは次の2種類のトークンがあるでしょう。 (この他にサービス/アプリケーション視点のものもありますが、今回は一旦対象外にします。) OAuth Access Token Personal Access Token つい、このAPI使いたいわ〜。そのためにはアクセストークンが必要、な

ritouです。 最近ちょっと気になってしまう人が多そうな話です。 passkeyが気になっちゃう 最近、passkeyという仕組みに注目が集まっています。 docomoも対応予定だと発表があった件です。 デバイス単位ではなく、プラットフォーマーのユーザー単位で秘密鍵が同期される...FIDO認証におけるアッピールポイントの一つである堅牢性みたいなポリシーを緩めてもリカバリー困難問題を解消しに行ったこの方針に、ついつい考えたくなるのがクレデンシャル管理です。 デバイス単位で秘密鍵が保存され、ローカル認証により正当なユーザーが利用したことを検証された上で公開鍵暗号を利用した認証処理が行われるのがFIDO認証 それがユーザー単位になるってことは...これまでのFIDO認証よりセキュリティレベル?は下がってしまうよね??? Attestationのところが空になったらサービス側が検証できなくなる

ritouです。 先日の idcon っていう勉強会で Android の passkey 対応について聞きました。 Googleアカウント+Chromeパワーでなんとかしちゃうのかなと思っていましたが、Android端末間での同期みたいな感じのようでした。そこで、想定される機種変更の時にどうなるかを確認してみました。 準備 詳しい人がTweetしてたこの辺りのドキュメントを見て、ベータテスターになってGoogle Play Services betaを入れることで使えるようになりました。CanaryじゃないChromeでも使えます。あと、Androidたんで困った時は再起動とかガチャガチャしてれば使えるようになります。 後は端末を2台用意。Android Srudio使っても普通にできそうだけど実機があるのでおk。 では早速みてみましょう。 動作確認に使ったのはここです。 ログインの時は

ritouです。 背景 これまで数年に渡り、「新規登録/ログイン時に登録状態がわかるレスポンスを返してくれるな。」というお話をしてきました。 SMSやEmailを入力して認証コードなどを送るタイプのログイン方法でも同様の実装は可能であり、表向きは「認証コードを送信したよ。受け取った値を入れてくれよな。」としつつ実際は既に登録済みだからログインからこい、未登録だから新規登録から来い見たいな内容を送りつつ、画面では正規のユーザーと同様のトークンなりを送り検証が絶対通らん! みたいなのを実装したりしています。 ではこれをWebAuthnなりネイティブ機能で提供されるFIDO認証でこれを実現したいとなった時にどうしたら良いか、細かく考えたらやっぱりめんどいなって話をします。 想定する環境 パスワード認証と組み合わせる2FA用途ではなく、FIDO認証のみでログインさせる 最初にユーザー識別を行うかど

ritou です。 異なるサービス間のデータのやりとり 前回の記事にちょっと書きましたが、OAuthにおいてUser-Agent(ブラウザ)経由で異なるサービス間を行ったり来たりする部分があります。 その際に、当然データのやりとりが行われているわけですが、今日はここに注目します。 2つのサービスがある時に、どのようにデータをやりとりするかを整理することで一般的なWebアプリケーション開発にも生かせるかもしれません。 5つの方法 今回は5つの方法を紹介します。 の前に、2種類の通信方法が出てきます。 FrontChannel : User-Agentを経由したリダイレクト BackChannel : 2つのサービスのサーバ間でのやりとり ここから紹介するやり方は、これらを単体で利用、もしくは組み合わせて利用します。 1. FrontChannel GET いわゆる クエリパラメータのついたリ

ritouです。 今日は OAuth 2.0 の話題で少し頭の体操をしましょう。 いきなりまとめ 今回は OAuth 2.0 の Refresh Token を用いて非同期の処理を実装するケースはよくある "Refresh Tokenの有効期限がない=無効化されない" という前提の設計を見かけるが、よくないと思う 無限に有効な Refresh Token が必要になりそうな機能は Client Credentials Grant に持っていくのも一つの手では みたいな話をします。 OAuth 2.0 の Refresh Token 仕様の参照とかはめんどいのでざっくりまとめると Access Token を更新するために利用されるトークン Resource Owner が介入しない非同期なタイミングでも利用される場合がある 有効期限切れや AuthZ Server / Resource O

こんにちは、ritouです。 昨日、こんなTweetをしました。 これは何かという話です。 いきなりまとめ Googleへのログインの話 ではない カレンダーやメールなど古からのプロトコルでは パスワード認証を前提としたものがある それが OAuthに置き換わる 感じ PIM系プロトコルとパスワード認証(認可?) このネタどこかに書いた気がするな...ってので振り返ると、メールについてこの前記事書いてました。 今回も同じ話ですね。一部を除いてこれのリミットが来たってところでしょう。 OIDCじゃないのか?というところは、カレンダーやメール、アドレスブック情報へのアクセスが目的なのでやってることはリソースアクセス、なのでOAuth 2.0すね。 校長「GoogleがPIM系のパスワード認証を駆逐し始めるまでに12年かかりました。」

ritouです。 少し前に、FIDOアライアンスからこんなドキュメントが出ていました。 これは何の話でしょうか?というのを整理しておきましょう。 これまでの課題 : デバイス毎に認証機(公開鍵)の登録が必要 しかし、依然として残っている課題は、ユーザーが新しいデバイスでサービス毎にFIDO認証の登録をする必要があることです。その最初の登録でパスワードが必要になる場合もあります。このとき、携帯電話やラップトップPCを変更すると、そのときに登録したFIDO認証資格情報はどうなるでしょうか?また、(携帯電話をなくしたときなどの)アカウントリカバリー(再設定)はどのようにすれば良いでしょうか?現在のFIDO認証モデルのままでは、このリカバリーが困難です。 所謂リカバリー難しい問題ですね。 これは、コンシューマーがより多くのサービスでFIDO認証を使うにあたって、複数デバイスを使ったり定期的に新しい

ritouです。 OAuth認証やOAuthログインなんて言うのは平成で終わりにしないといけなかったんですが、そううまくはいかないようです。 メールソフトのやっていること メーラーとかメールソフトのやることといえば メール関連の処理を行う のがメインですね。 他に色々できるやつもあるのかもしれませんが 置いときます 。 メールソフトにログインする訳ではなく、対象メールアカウントへのアクセス権限が欲しいだけです。 ここは昔からなんとなく理解しやすい気がする。しない?これこそリソースアクセスですよね。 ずっと前から、メールソフトでは、 メールサーバーを設定することで対象リソースを把握 ユーザー名、パスワードを設定することでリソースオーナーであることを確認してメールにアクセス していたわけですね。 この辺りについて意識が高まっていた10年前にブログ記事を書いたことがあったんですが、メールとかカレ

ritouです。 なんか反応いっぱいあったこれですが 一番伝えたかったのは ログインだけなら(ClientSecret)いらねーじゃん なのでその部分を書きます。特に新しい話ではありません。 まとめ まとめます。 OIDCで新規登録やログインさせたいだけ、かつUserInfo API叩かなくていいなら、 client_secretはいらないよ! Implicitって言っても、OAuth 2.0 の response_type=token は使わん方がいいけど OIDC の response_type=id_token は使っていい みんな大好きSAMLと大体一緒よ。しらんけど。 こんなところですね。 ID連携の時、リソースアクセスしてる? OIDC Core ってのは IDTokenによる "認証イベント" 情報、ユーザーの属性情報を受け渡し UserInfo APIによる最新のユーザー属