サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
Appleイベント
zenn.dev/ritou
(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 です。 少し前にパスキーと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です。 前回は、パスキーやパスワードマネージャーを使う時の認証要素について触れました。 今回は、 同じ要素の認証を重ねる意味 同一端末やパスワードマネージャーだけで完結する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です。 なんか反応いっぱいあったこれですが 一番伝えたかったのは ログインだけなら(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です。 この話に乗っかっていきます。 3行で ログアウト時にJWTを無効化できない実装は今後脆弱性診断で「OWASP Top 10 2021違反」と指摘されるようになりそう(今も個別にされてるかもしれないけど) JWTは単純なフォーマットなので、ステートレスなセッション管理においてログアウトしたときに文字列自体を無効化できない件は独自エンコード方式(一般的にフレームワークのCookieストアと呼ばれているもの)でも起こり得る 「セッションID vs JWTで内包」 以外にも 「セッションIDをJWTに内包」もあり得る。既存の機能を残しつつ「JWTで武装」する選択肢も考えてみてはどうか。 ステートレスなセッション管理でログアウトの際に文字列自体を無効化できない問題 これは前から言われていますし、駆け出し何とか勢のQiita記事に書かれるぐらいには一般的です。 2
次のページ
このページを最初にブックマークしてみませんか?
『ritouさんの記事一覧』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く