こんにちは、富士榮です。 ちょっと前に某所でダメダメな認証系の技術実装ってなんだろうねぇ、、という話をしていたことをXで呟いたところ、色々とご意見を頂けましたのでまとめて書いておきます。
滅びてほしい認証系の実装の話
こんにちは、富士榮です。 ちょっと前に某所でダメダメな認証系の技術実装ってなんだろうねぇ、、という話をしていたことをXで呟いたところ、色々とご意見を頂けましたのでまとめて書いておきます。
パスキーの概要とKeycloakでの動作確認 - Qiita
なお、上記は2023年12月時点でのFIDOアラインスの定義に基づきます。これらの用語はこれまで定義が変化してきたり、FIDOアライアンスの定義が業界のコンセンサスを得ていないケースで意味の揺れがあったりすることもありました。 同期するもののみを指すケース パスキーはFIDOアライアンスの発表では、「マルチデバイスFIDOクレデンシャル」の通称という扱いでした34。つまり、当初はクラウド同期して複数デバイスで使えるもののみがパスキーでした。しかし、パスキーの勢いを見てか分かりませんが、セキュリティキーベンダーが自分たちもパスキーだと主張し始めました5。その後FIDOアライアンスもSingle-device passkey(現: デバイスバウンドパスキー)を定義し、同期しない従来のFIDOクレデンシャルもパスキーとなりました6。 認証方式を指すケース パスキーは「FIDOクレデンシャル」です
パスキーとID連携の関係を考察する際の観点｜ritou
パスキーの登場以来、ID連携、特にソーシャルログインは認証方法として比べられることが多くなりました。この記事では、この2つを比較したりその関係を考察する際に意識しておくべき観点を整理しておきます。 それぞれの特徴両者は異なる特徴を持っています。 パスキー 用途: 認証 パスキーの管理: プラットフォームが提供するパスワードマネージャー、サードパーティーのパスワードマネージャー、セキュリティキー、ブラウザ 属性情報: 一緒に保持できて引き回せるデータは User Handle ぐらい ID連携 用途: 新規登録、認証、属性情報の取得/同期 アカウント情報の管理: Identity Provider 属性情報: プロフィール情報、確認済みメールアドレスなどを取得可能なのが一般的 特徴が異なるために、導入箇所や意味合いも異なります。 ざっと思いつくのが 新規登録 ログイン 再認証 ぐらいでしょう
ユーザー アカウント、認証、パスワード管理に関する 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」ではありません）
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ページを開く
