滅びてほしい認証系の実装の話
こんにちは、富士榮です。 ちょっと前に某所でダメダメな認証系の技術実装ってなんだろうねぇ、、という話をしていたことをXで呟いたところ、色々とご意見を頂けましたのでまとめて書いておきます。 考えていると結局のところ、サービス提供側が意図していることとは全然違うことが起きている気がするので、この辺はしっかり考えて実装したいところですね。（実装ミスは問題外として） カテゴリ滅びてほしいもの実装側がやりたいこと利用者が感じること実際に起きていること代替手法認証CAPTCHAbot避けぐにゃぐにゃ文字が読めない バイクと自転車の違いとは？ユーザの離脱、カゴ落ちパスキーの利用 新しいタイプのCAPTCHA（通常は画面に出ない） リスクベース認証との組み合わせによる抑制認証パスワード誰でも使える認証手段の用意忘れる。複雑なパスワードをそれぞれのサービス毎に管理するのは無理パスワードの使い回し。パスワード
パスキーの概要とKeycloakでの動作確認 - Qiita
なお、上記は2023年12月時点でのFIDOアラインスの定義に基づきます。これらの用語はこれまで定義が変化してきたり、FIDOアライアンスの定義が業界のコンセンサスを得ていないケースで意味の揺れがあったりすることもありました。 同期するもののみを指すケース パスキーはFIDOアライアンスの発表では、「マルチデバイスFIDOクレデンシャル」の通称という扱いでした34。つまり、当初はクラウド同期して複数デバイスで使えるもののみがパスキーでした。しかし、パスキーの勢いを見てか分かりませんが、セキュリティキーベンダーが自分たちもパスキーだと主張し始めました5。その後FIDOアライアンスもSingle-device passkey(現: デバイスバウンドパスキー)を定義し、同期しない従来のFIDOクレデンシャルもパスキーとなりました6。 認証方式を指すケース パスキーは「FIDOクレデンシャル」です
認証と身元確認の強度について改めて考えてみようと思った - Qiita
本記事は Digital Identity技術勉強会 #iddance Advent Calendar 2023 の11日目の記事です。 最近、パスキーのことばかり考えていましたが、その中だったり、別の文脈だったりで、「認証の強度や身元確認レベルと利用可能な機能の関係」を考える機会が、ちょいちょいありました。 例えば『パスキーでアカウント登録するを実施するのが理想的だよね』という意見を聞きます。その一方で、『パスキーでphishingの対策はできるかもしれないけど、誰でも簡単にアカウント作れたらだめだから、電話番号の登録はどのみち必要。iCloud keychain/画面ロック有効にしてない人もいるし、あくまでパスキーを全面にだすのは微妙じゃない？』という意見も聞きます。 そんな話を聞いていたら、アカウントを認証強度や身元確認強度の観点から、どういう状態があって、各状態にどういうリスクがあ
パスキーとID連携の関係を考察する際の観点｜ritou
パスキーの登場以来、ID連携、特にソーシャルログインは認証方法として比べられることが多くなりました。この記事では、この2つを比較したりその関係を考察する際に意識しておくべき観点を整理しておきます。 それぞれの特徴両者は異なる特徴を持っています。 パスキー 用途: 認証 パスキーの管理: プラットフォームが提供するパスワードマネージャー、サードパーティーのパスワードマネージャー、セキュリティキー、ブラウザ 属性情報: 一緒に保持できて引き回せるデータは User Handle ぐらい ID連携 用途: 新規登録、認証、属性情報の取得/同期 アカウント情報の管理: Identity Provider 属性情報: プロフィール情報、確認済みメールアドレスなどを取得可能なのが一般的 特徴が異なるために、導入箇所や意味合いも異なります。 ざっと思いつくのが 新規登録 ログイン 再認証 ぐらいでしょう
Public preview: Azure Container Apps built-in authentication Microsoft Azure Container Apps | Azure の更新情報 | Microsoft Azure
Azure を探索 Azure について 安全かつ将来を見据えた、オンプレミス、ハイブリッド、マルチクラウド、エッジのクラウド ソリューションについて調べる グローバル インフラストラクチャ 他のどのプロバイダーよりも多くのリージョンを備える持続可能で信頼できるクラウド インフラストラクチャについての詳細情報 クラウドの経済性 Azure の財務上および技術的に重要なガイダンスを利用して、クラウドのビジネス ケースを作成する 顧客イネーブルメント 実績のあるツール、ガイダンス、リソースを使用して、クラウド移行の明確なパスを計画する お客様事例 成功を収めたあらゆる規模と業界の企業によるイノベーションの例を参照する
雰囲気でOAuthを使っていたエンジニアがOAuthサーバ(RFC6749)を自作してみる
はじめに Auth屋さんの本やその他有識者のBlogなどを読むことで少しながらOAuthやOIDCの仕組みが理解できてきました。 そんななかで以下の記事が大変勉強になりました。 ↑の記事ではRubyで実装されているのですが、これを参考というかほぼ丸コピですがgolangで実装してみたいと思います。 コードは以下にあります。 仕様 OAuthサーバでは認可エンドポイントとトークンエンドポイントを実装する必要があります。 認可とトークンエンドポイントの2つに加えてユーザ認証を行うエンドポイントを作ります。 今回は元記事と同じようにFormに入力したユーザ&パスワードを受け取り確認します。 RFC6749に関する仕様は元記事の2.注意点と同じになるはずです。 「はずです」というのは恥ずかしながらまだ完全な理解に至っておらず今もRFCを読みながら答え合わせ中です。 ぜひ認識違いがあればご指摘くださ
ユーザー アカウント、認証、パスワード管理に関する 13 のベスト プラクティス2021 年版 | Google Cloud 公式ブログ
※この投稿は米国時間 2021 年 5 月 7 日に、Google Cloud blog に投稿されたものの抄訳です。 2021 年用に更新: この投稿には、Google のホワイトペーパー「パスワード管理のベスト プラクティス」のユーザー向けとシステム設計者向けの両方の最新情報を含む、更新されたベスト プラクティスが含まれています。 アカウント管理、認証、パスワード管理には十分な注意を払う必要があります。多くの場合、アカウント管理は開発者や製品マネージャーにとって最優先事項ではなく、盲点になりがちです。そのため、ユーザーが期待するデータ セキュリティやユーザー エクスペリエンスを提供できていないケースがよくあります。 幸い、Google Cloud には、ユーザー アカウント（ここでは、システムに対して認証を受けるすべてのユーザー、つまりお客様または内部ユーザー）の作成、安全な取り扱い、
OpenID Connect 1.0 with Spring Security #jjug_ccc #jjug_ccc_b / oidc-with-spring-security
OpenID Connect 1.0は、OAuth 2.0をベースとした認証プロトコルです。このセッションでは次の内容をわかりやすく解説します。 - OpenID Connect 1.0の概要とフロー - なぜOAuthは「認可」でOpenID Connectは「認証」なのか - Spring Securityの利用方法 このセッションは中級者向けです。次の知識を前提として解説します。 - OAuth 2.0の認可コードグラントのフローを説明できる - Spring Security 5.xのOAuth 2.0機能を使ったことがある（既に非推奨となっている「Spring Security OAuth2」ではありません）
CheatSheetSeries/cheatsheets/Authentication_Cheat_Sheet.md at master · OWASP/CheatSheetSeries
Authentication (AuthN) is the process of verifying that an individual, entity, or website is who or what it claims to be by determining the validity of one or more authenticators (like passwords, fingerprints, or security tokens) that are used to back up this claim. Digital Identity is the unique representation of a subject engaged in an online transaction. A digital identity is always unique in t
WebAuthnを用いたパスワードレス生体認証のユーザビリティ調査
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは!! Yahoo! JAPAN研究所の山口修司です。 突然ですが、生体認証は好きですか？ 最近はスマホで生体認証が利用できるようになったので生体認証を使うシーンが増えていると思います。私は、使い勝手的に（以後ユーザビリティと書きます）、パスワードを覚えたり入力したりしたくないので、生体認証が選べるなら積極的に使っています。 Yahoo! JAPANでは、2018年にセキュリティとユーザビリティの両立を目指して、Yahoo! JAPAN IDに生体認証を導入しました。 ヤフー、Androidスマートフォンのウェブブラウザー上でのログインが指紋認証などの生体認証に対応 Webサイトの生体認証の仕組みには、認証に関するグローバ
OAuth & OpenID Connect の不適切実装まとめ - Qiita
はじめに 世の中の OAuth & OpenID Connect の不適切実装の事例をリストしています。公式ドキュメントに「ドラフト段階の仕様をサポート」と断り書きが書いてあっても、最終仕様に違反している場合はリストしています。内容は適宜更新していきます。OAuth & OpenID Connect を実装する際の注意事項として参照していただければと思います。 仕様書を読むのは面倒だけど、OAuth & OpenID Connect をちゃんと実装しないといけない立場にある方は、是非 Authlete の使用を検討してください。(by Authlete 創業者) 事例 1. リダイレクト URI を正しく検証していない John Bradley 氏の記事「Covert Redirect and its real impact on OAuth and OpenID Connect」を参照し
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
