タグ

認証と仕様に関するlocke-009のブックマーク (5)

  • デジタル認証アプリとのID連携で使われている標準化仕様と勘所

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

    デジタル認証アプリとのID連携で使われている標準化仕様と勘所
  • パスキーは本当に2要素認証なのか問題、またの名を、あまり気にせず使えばいいと思うよ。|kkoiwai

    この記事の内容は、個人の意見であり感想です。くれぐれもよろしくおねがいします。 とりあえずドラフトですが公開します。識者のみなさまの暖かく、そして鋭いツッコミを期待します。 パスキーについて、非常にわかりやすいブログをえーじさんが書いてくださいました。コレを読んで頂ければほとんどのことが分かると思います。 先日の次世代Webカンファレンスで、私は、「結局、パスキーは秘密鍵と公開鍵のペア」と申し上げた立場からも、この疑問はごもっともだと思いましたので、すこし、私の思うところを述べたいと思います。 パスキーは2要素認証の場合が多いほとんどのユーザは、OS標準のパスキーを使うのではないかと思います。そして、生体認証、もしくは画面ロック用のパスワードやPIN等が設定されていない限り、OS標準のパスキーを使うことができません。そして、OS標準パスキーの利用時には、生体認証もしくは画面ロック解除のため

    パスキーは本当に2要素認証なのか問題、またの名を、あまり気にせず使えばいいと思うよ。|kkoiwai
  • Twitter、DMの再仕様変更 スパム軽減目的でBlueからのDMも「リクエスト」タブへ

    Twitterは7月13日(米国時間)、ダイレクトメッセージ(DM)の仕様変更をツイートで発表した。「DM内のスパムの数を減らすのに役立つメッセージ設定を追加する」としている。 この新メッセージ設定では、フォローしていないBlueユーザーからのDMを「メッセージ」タブではなく「リクエスト」タブに保存するようになる。 以前の青バッジと異なり、Twitter Blueは金さえ払えばほぼ誰でも取得できる。スパム目的でBlueに加入するユーザーがいてもおかしくはない。この仕様変更は、そうしたBlueユーザーからのスパムを軽減する目的のようだ。ただし、スパムはブロックされるのではなく、リクエストタブに保存される。 また、それまで「すべてのアカウントからのメッセージリクエストを許可する」設定にしていたユーザーの設定を自動的に新たなメッセージ設定に変更する。 つまり、ユーザーがそれに気づいて元に戻さない

    Twitter、DMの再仕様変更 スパム軽減目的でBlueからのDMも「リクエスト」タブへ
  • 電子メール送信に関する技術

    ふと気になって調べたことの備忘メモです ✍ (2022/4/2追記)Twitterやはてブで色々とご指摘やコメントを頂いたので、それに基づいて加筆と修正をおこないました 特に、幾つかの技術については完全に誤った説明をしてしまっており、大変助かりました…ありがとうございました🙏 (2024/8/13追記)今年に入って、実務で使える メール技術の教科書というが出版されています🎉 私も買って読みましたが、電子メールに関するトピックについて広くカバーされていました パブリッククラウドに関する記述は少な目ですが、メールサーバーを自身で構築する方法が紹介されていたりなど、より基礎的な内容に主眼をおいているだと思います なぜ調べたか メール送信機能のあるWebアプリケーションを開発・運用していると、 特定のアドレスに対してメールが届かないんだが とか MAILER-DAEMONなるアドレスからメ

    電子メール送信に関する技術
  • OAuthにおける認可コード横取り攻撃とその対策

    OAuthにおける認可コード横取り攻撃とその対策 Jul 5, 2021 前回の記事で示したように、カスタムURLスキームを偽装した不正アプリは正規アプリへのディープリンクを乗っ取れる。この挙動の悪用シナリオとして、正規アプリと認可サーバー間のOAuthフローにおける認可コード横取り攻撃が知られている。この攻撃への対策を把握するためにiOS環境でシナリオを再現し、PKCEの有効性を確認した。 要約 OAuth 2.0の拡張機能であるPKCEを導入することで認可コード横取り攻撃を無効化できる。OAuth 2.0の仕様では、認可サーバーはネイティブアプリをクライアント認証できない。そのため、認可サーバーは認可コードを横取りした不正アプリと正規アプリを識別できない。しかし、PKCEの仕組みにより認可サーバーは正規アプリを識別できるようになり、認可コード横取り攻撃の検知が可能となる。 ネイティブア

    OAuthにおける認可コード横取り攻撃とその対策
  • 1