サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
都知事選
zenn.dev/ritou
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です。 タイトルの通り、お話をしてきました。 それではどうぞ。 動画 (2024/4/12: 動画が公開されていたので追記しました) 内容 OIDF-Jでエバンジェリストをしています。ritouです。 今日はパスキーとID連携についてお話させていただきます。 この発表では次の3点について話します。 それぞれの特徴/特性 ID連携のIdP/RPそれぞれがパスキー認証をサポートすることで得られるもの 関連するOIDC/OAuth 2.0の仕様 まずはそれぞれの特徴、特性から見ていきます。 パスキー、具体的には「FIDOクレデンシャルを用いた認証方式」について、特徴を振り返ります。 まずは公開鍵暗号を利用すること、ブラウザなどの仲介によるフィッシング耐性による安全性です。 そして、利用者の確認としてローカル認証と呼ばれる画面ロック解除の仕組みを利用すること、各プラットフォー
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です。 前回は、パスキーやパスワードマネージャーを使う時の認証要素について触れました。 今回は、 同じ要素の認証を重ねる意味 同一端末やパスワードマネージャーだけで完結するMFA あるアカウントに紐づけられて同期されるクレデンシャル管理 についての 基本的な整理 をします。 前回に続き、書いていることは無難な内容だと思います。 (長いので先に)まとめ 単一要素を重ねる意味について、要素の種類によっては有効な場合もある SYK を重ねるケースは決済などでまだ見られるが今後は淘汰されていくのでは? SYH の場合、管理デバイスを分離することで安全性を上げられる。ただし手間は増えるしフィッシング耐性は別途考慮する必要あり。 SYA を重ねる=単一SYAの精度を上げるのと同じ扱いになりそう(顔だけ、指紋だけ -> 顔 + 指紋など) 同一端末やパスワードマネージャー内で完結するMFAやプ
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です。 先日の 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です。 なんか反応いっぱいあったこれですが 一番伝えたかったのは ログインだけなら(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による最新のユーザー属
ritouです。 何の話か? このあたりの話です。 FE + BE が存在するID連携 SPAやネイティブアプリといったフロントエンドと、バックエンドサーバーを組み合わせたサービスでID連携を行う際、バックエンドサーバーを起点、終点としたフローを考えられるとセキュアにできますよ、みたいな話を前に書きました。 次に、認可サーバー/リソオースサーバーとのやりとりを Backend Server に任せる パターンです。 リソオース... 前提として、モバイルアプリやSPAとBackend Serverの間にセッションが確立しており、Client は認可リクエストのURLにリダイレクトするだけ、認可レスポンスのパラメータを Backend Server に送るだけです。 このセッションが確立している前提について、ログイン後のID連携などではセッションが確立されているが未ログイン状態のソーシャルロ
ritou です。 前の記事でちょっと確認済みメアドについての記載をしたあと、Twitterでちょっとやりとりしたり個別にDMで質問が来たりしたのでまとめます。 まとめ "確認済みメアド" のユースケースはいくつかある 新規登録時に自サービスで確認処理を行わずに利用 未登録ユーザーがソーシャルログインしてきた時に既存ユーザーとの紐付け IdPからもらった確認済みメアドをそのまま使っていい場合とそうじゃない場合がある 自サービスで提供しているメールアドレスかどうかで変わる部分を許容するかどうか email_provided のようなclaim があると便利かもしれない 確認済みメアドのユースケース 新規登録時の確認処理をスキップ これはID連携、ソーシャルログインのメリットとしてずっと言われているものです。 IdPで確認済みなのでRPは確認せずに信用して使おう というお話です。 よく知られて
ritouです。 Digital Identity技術勉強会 #iddance Advent Calendar 2021 の18日目の記事です。(代わりに書いた) 今回のお話は 新しいサービス作る時とか、登録/ログインフロー考えるよね?考えない?おじさんそう言うお仕事してるの パスワードレスな認証方式やID連携とか使いだすと、登録もログインも一緒でええかみたいな話も出てくるでしょ?こない?おじさんとこは出るの 分けたまま、一緒にする場合にそれぞれ気をつけないといけないことを整理しましょ というお話です。 1. パスワード認証時代は分けてりゃ良かった パスワード認証の場合、新規登録とログインでUXの要件が異なります。 新規登録 : ユーザーが主張する識別子や連絡先としてメールアドレスやSMS番号を確認し、パスワードを登録させる ログイン : ユーザーが主張する識別子とパスワードを入力させて検
おはようございます。ritouです。 Digital Identity技術勉強会 #iddanceのカレンダー | Advent Calendar 2021 - Qiita 4日目の記事です。 前にこんなTweetをしてしまったので書きます。 参考記事 ITS SINGLE STEP NOT FACTOR — clarifying more FIDO terminology | by Ackermann Yuriy | WebAuthn Works | Nov, 2021 | Medium いろんなサービスで2段階認証やられてますね。FIDOだと2要素認証だと言われてます。でも、プラットフォームの生体認証使ったりセキュリティキーに生体認証載ったら一回のユーザーアクションでいけますよね?それって段階としては1ですか?要素は2?要素と段階どっちが強いんです?…みたいな混乱を解消するための記事で
こんばんは、ritou です。 今日は JWTの無効化の方法はいっぱいあるよ って話を書きます。 単体での無効化(jti, 文字列全体のハッシュ) これが最も一般的な JWT無効化の方法 と言えるかもしれません。 ちょっと前に話題になった「Stateless」なユースケースにおける無効化できないみたいな話に絡むところでしょう。 The "jti" (JWT ID) claim provides a unique identifier for the JWT. 例えば失効対象の jti のリストを管理することで無効化判定ができるでしょう。 有効期限を持つかどうかにより対象の jti をいつまで保持するか、などの細かい要件は変わります。 これ以外にも、JWTに含まれる claim を利用した検証 ってのは 無効化管理/判定 をしていると言いかえることもできます。 時刻での無効化(iat, ex
次のページ
このページを最初にブックマークしてみませんか?
『ritouさんの記事一覧』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く