Content-Length: 404723 | pFad | http://b.hatena.ne.jp/latteru/%E8%AA%8D%E8%A8%BC/

[B! 認証] latteruのブックマーク

タグ

認証に関するlatteruのブックマーク (30)

  • パスキーによる認証をブラウザで実装してみる

    パスキーによる認証をブラウザで実装してみる 2025.02.08 パスキーとはパスワードに代わる認証方法で、生体認証やデバイス PIN を使ってログインができる仕組みです。ユーザーはパスワードを覚える必要がなく、またフィッシング攻撃にも強いという点からよりセキュア認証方法として注目を集めています。この記事では WebAuthn を使ってパスキーをブラウザで実装する方法を紹介します。 パスキーとはパスワードに代わる認証方法で、生体認証やデバイス PIN を使ってログインができる仕組みです。ユーザーはパスワードを覚える必要がなく、フィッシング攻撃にも強いという点からよりセキュア認証方法として注目を集めています。また指紋認証や顔認証のように簡単な操作で Web サービスにアクセスできるようになるため、ユーザビリティの向上にもつながります。 パスキーは 2022 年頃から企業や団体により対応が表明

    パスキーによる認証をブラウザで実装してみる
  • 初心者向けJWT講座:JSON Web Tokenを使った認証の仕組み

    JWTって何? JWTはJSON Web Tokenの略です。 まずは完成されたJWTを見てみましょう。 eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c この文字列がJWTです。 JWTの特徴を見てみる よく見ると、この文字列は 「.」(ドット) で区切られています。 JWTは次の3つのパーツから構成されています。 ヘッダ(Header) ペイロード(Payload) 署名(Signature) ただの文字列じゃない? JWTは単なる文字列ではありません。 実は、この「ヘッダ」や「ペイロード」をデコードすると、JSON形式のデータ

    初心者向けJWT講座:JSON Web Tokenを使った認証の仕組み
  • iOS で Google パスワード マネージャーのパスキーを利用できるようになりました  |  Blog  |  Chrome for Developers

    公開日: 2025 年 1 月 16 日 パスキーは、パスワードに代わるより安全でユーザー フレンドリーな方法です。パスキーを使用すると、ユーザーは生体認証センサー(指紋認証や顔認証など)、PIN、パターンを使用してデバイスの画面のロックを解除し、アプリやウェブサイトにログインできます。パスキーを使用すると、ユーザーはパスワードを覚えたり管理したりする必要がなくなり、フィッシングの心配も不要になります。iOS と iPadOS で Google パスワード マネージャー(GPM)のパスキーを利用できるため、Chrome はすべてのオペレーティング システムでパスキーを同期します。 Google パスワード マネージャーのパスキーが iOS 17 以降で利用可能に iOS 17 以降(および iPadOS 17 以降)の Chrome ユーザーは、Google パスワード マネージャーでパス

    iOS で Google パスワード マネージャーのパスキーを利用できるようになりました  |  Blog  |  Chrome for Developers
  • ID連携を理解しよう(1) ID連携の概要とOAuth, OIDCで実現できること

    ritou です。 あけましておめでとうございます。2025年はID連携の話をしましょう。 昨年、仕様策定から10年を迎えたOpenID Connectですが、関連仕様の策定は続いています。特に最近はDigital Identity Walletを支える仕様群の策定がお盛んです。新しい技術をキャッチアップするためにも、ベースとなるID連携の概要から理解していく必要があると考えています。 今回はID連携とは、というところとどうしても混乱してしまうOAuthとOIDCの用途について理解するための説明をします。OAuth/OIDC関係はどうしても記事が長くなってしまうので、今後のモチベーションのためにも「ID連携を理解しよう(1)」としています。 ID連携とは ID管理などで使われるID(=Identity)とはユーザーの属性情報の集合です。 ユーザー識別子(User Identifier)やメ

    ID連携を理解しよう(1) ID連携の概要とOAuth, OIDCで実現できること
  • SSHでも二要素認証を使いたい | IIJ Engineers Blog

    社会人生活の半分をフリーランス、半分をIIJで過ごすエンジニア。元々はアプリケーション屋だったはずが、クラウドと出会ったばかりに半身をインフラ屋に売り渡す羽目に。現在はコンテナ技術に傾倒中だが語りだすと長いので割愛。タグをつけるならコンテナ、クラウド、ロードバイク、うどん。 【IIJ 2024 TECHアドベントカレンダー 12/6の記事です】 今年のIIJアドベントカレンダーは「運用」がテーマということなので、運用に欠かせない必携ツール筆頭であるSSHを取り上げ、SSHの秘密鍵を安全に管理する方法について考えたいと思います。 たとえSSH秘密鍵が漏洩しても、安全を確保する方法 踏み台サーバにSSH秘密鍵を置かずに利用する方法 SSH秘密鍵の安全な置き場所を考える SSH秘密鍵は一般的に ~/.sshにファイルとして管理されていると思いますが、不安に感じることはありませんか? ノートPC

    SSHでも二要素認証を使いたい | IIJ Engineers Blog
  • OAuth/OIDCのJWTまとめ - Qiita

    はじめに Wikipedia の JWT (JSON Web Token) に関する記事が誤っていたので、2020 年 5 月 9 日、英語版、日語版ともに修正を行いました。 修正前の記事では、JWT のことを「JSON をベースとしたアクセストークンのためのオープン標準である」と説明していました。しかし JWT は用途を限定しない汎用的なデータフォーマットです。アクセストークンのフォーマットとして JWT を採用することは、JWT の応用事例の一つに過ぎません。なお、アクセストークンのフォーマットは必ずしも JWT とは限りません。→ 参考:『図解 JWS/JWE/JWT/IDトークン/アクセストークンの包含関係』 JWT を知らない状態で OAuth と OpenID Connect の学習を始めると、「JWT はアクセストークンのための技術である」、「JWT はユーザ認証のための技

    OAuth/OIDCのJWTまとめ - Qiita
  • SSH接続を10倍速くするたった3行の設定 - Qiita

    今回は、SSH接続を劇的に高速化する方法をご紹介します。たった3行の設定を追加するだけで、接続時間を10分の1に短縮できます。しかも、2回目以降の接続では認証も自動的に行われるので、パスワードやパスフレーズの入力も不要になります。 要点 .ssh/configファイルのHost *セクションに以下の3行を追加するだけです。 詳しい説明 1. ControlMaster auto この設定で、1つのSSH接続で複数のセッションを共有できるようになります。新しくSSH接続を確立するたびに認証情報を入力し直す手間が省けて、接続がぐっと速くなります。具体的には: 初回の接続時のみ認証が必要 2回目以降は既存の接続を再利用するため、認証プロセスをスキップ パスワードやパスフレーズの入力が不要になり、接続がほぼ瞬時に完了 2. ControlPath ~/.ssh/mux-%r@%h:%p Contr

    SSH接続を10倍速くするたった3行の設定 - Qiita
  • マイクロサービス間通信における認証認可およびアクセス制御

    はじめに 2023年4月に基盤エンジニアとして Ubie に入社しました nerocrux です。主に Ubie の ID 基盤の開発と保守運用を担当しています。 この記事は、2023 Ubie Engineers アドベントカレンダー 5 日目の記事となります。 Ubie では、モジュラモノリスを採用しつつ、マイクロサービスアーキテクチャも採用しており、領域によってサービスを分けて、それぞれの担当チームが開発と保守運用をしています。 クライアントから一つのリクエストを受け取ったあとに、Ubie のバックエンドではリクエストを受け取ったサービスだけがそのリクエストを処理することもあれば、別のサービスにディスパッチし、複数のサービスがひとつのリクエストを処理して結果を返すこともあります。 マイクロサービス間の通信が Ubie の内部で発生したとしても、必ずしも無制限で自由に行われていいわけで

    マイクロサービス間通信における認証認可およびアクセス制御
  • パスワード不要の認証技術「パスキー」はパスワードよりもエクスペリエンスが悪いという批判

    FIDOアライアンスが仕様を策定した「パスキー」は、パスワードではなく生体情報を用いて認証する「FIDO 2.0」を「Webauthn」標準に基いて利用して得た資格認証情報をデバイス単位で管理運用する技術です。このパスキーが抱える問題点について、Webauthn標準に関わったエンジニアのFirstyearことウィリアム・ブラウン氏が自身のブログで解説しています。 Firstyear's blog-a-log https://fy.blackhats.net.au/blog/2024-04-26-passkeys-a-shattered-dream/ Webauthnがパスワードに代わる認証技術として大きな可能性を秘めていると考えていたブラウン氏は、2019年にオーストラリアからアメリカに渡り、友人と共にWebauthnのRust実装であるwebauthn-rsの開発を始めました。その過程で

    パスワード不要の認証技術「パスキー」はパスワードよりもエクスペリエンスが悪いという批判
  • 「認証」を整理する | IIJ Engineers Blog

    英語の「Authentication」を整理する ここからは先ほどの分類で言うところの「ユーザ認証」としての「認証」、つまり英語の「Authentication」に該当する「認証」について、さらに整理を進めていきます。 先ほど、「ユーザ認証」を「システムを利用しようとしているユーザを、システムに登録済みのユーザかどうか識別し、ユーザが主張する身元を検証するプロセス」と説明しました。「ユーザの識別」と「身元の検証」はユーザ認証に欠かせませんが、実際は他にも「ユーザの有効/無効状態の確認」や「検証に成功した場合の身元の保証(アクセストークンの発行等)」などの処理も一般的にユーザ認証のプロセスには含まれます。 ここで冒頭の「○○認証」を振り返りましょう。パスワード認証、SMS認証、指紋認証、顔認証は実はここで言うユーザ認証には該当せず、ユーザ認証中の一処理である「身元の検証」を担っていることがお

    「認証」を整理する | IIJ Engineers Blog
  • パスキーの基本とそれにまつわる誤解を解きほぐす

    2023 年は文句なく「パスキー元年」になりました。非常にたくさんのサービスがパスキーに対応し、2024 年はいよいよパスキー普及の年になりそうです。 記事では、パスキーの基を振り返ったうえで、パスキーでみなさんが勘違いしやすい点について解説します。 2023 年は当にたくさんのウェブサイトがパスキーに対応しました。例を挙げます: Adobe Amazon Apple eBay GitHub Google KDDI Mercari Mixi MoneyForward Nintendo NTT Docomo PayPal Shopify Toyota Uber Yahoo! JAPAN もちろんこのリストですべてではないですが、これらだけでも、世界人口のかなりをカバーできるはずで、まさに大躍進と言えます。もしまだパスキーを体験していないという方がいたら、ぜひこの機会にお試しください。

    パスキーの基本とそれにまつわる誤解を解きほぐす
  • いろんなウェブサービスにパスキーでログインしてみる

    2023/12/12 記事公開 2023/12/14 調査サービスの差し替え & コメント返信 はじめまして。kinmemodokiです。 この記事はDigital Identity技術勉強会 #iddance Advent Calendar 2023の12日目の記事です。 2023年では様々なウェブサービスがパスキーに対応し様々なログインUXが生まれました。 記事はそのさまざまなウェブサービスのパスキーによるログインUXの挙動をまとめ、挙動の考察を行いました。 記事で扱うのは「ウェブサービスのパスキーでのログインUX」についてであり、「パスキー周りの実装や技術」については基的に扱いません。 なお、記事では「WEB+DB PRESS Vol.136「特集2 実戦投入パスキー ─いまこそ実現、パスワードレス認証!」」の「第2章 パスキー時代の認証UX」を参考にしており、最低限の部分は

    いろんなウェブサービスにパスキーでログインしてみる
  • 社内をパスワードレスにするため頑張った話(前編) - Qiita

    シリーズ3部作です。 きっかけ 所属企業にて、2022年7月頃、情報システム部門に異動。種々の課題感に対する解決策(ここも話すと長くなる)としてMicrosoft 365 E5を導入することに決定。2023年1月にテナントにライセンスが適用され、E5セキュリティの実装を始める。同時に、組織内でIdPが複数運用されていることに対しても課題感を持っていたため、IdPの整理・統合も始める。 さらに同時期に、セキュリティ侵害の多くの原因が、パスワード漏洩だということを知る。 フィッシングメールでパスワードが漏洩(個人1位)し、クレジットカードが不正利用(個人4位)されたり、インターネット上のサービスに不正ログイン(個人10位)されたり…。スマホ決済の不正利用(個人5位)もですね。標的型攻撃による機密情報の窃取(組織3位)や、ビジネスメール詐欺(組織7位)も多くがパスワード入手を目的にしたものだと考

    社内をパスワードレスにするため頑張った話(前編) - Qiita
  • ドコモが「パスキー」を導入してフィッシング被害報告が0件に パスワードレス認証の効果

    パスワードを使わないパスワードレス認証であるパスキーを推進するFIDO Allianceは会見を開き、既に70億を超えるオンラインアカウントがパスキー利用可能な状態になって、利用が拡大していることをアピールした。国内でも利用が拡大しており、新たにメルカリがボードメンバーに加盟し、住信SBIネット銀行がアライアンスに加盟した。 FIDO Allianceの1年の取り組みが紹介された。写真左からメルカリ執行役員CISO市原尚久氏、LINEヤフーLY会員サービス統括部ID部長伊藤雄哉氏、FIDO Japan WG座長でNTTドコモのチーフ・セキュリティ・アーキテクト森山光一氏、FIDO Allianceエグゼクティブディレクター兼最高マーケティング責任者のアンドリュー・シキア氏、FIDO Alliance FIDO2技術作業部会共同座長でGoogle ID&セキュリティプロダクトマネージ

    ドコモが「パスキー」を導入してフィッシング被害報告が0件に パスワードレス認証の効果
  • Auth0にPassKeyが搭載されたぞ!!!

    はじめに 先日ふと Auth0 のダッシュボードを眺めていると、興味深い項目が表示されていました。 Passkey がある!!! なので、今回は Auth0 に搭載されたパスワードレス認証方式である Passkey の説明をしていきます。 なお、Auth0 の設定方法についてはAuth0 からリリースされた記事を参考にして、記載しています。 パスワード認証の課題 Passkey の説明をするまえに、パスワード認証の課題について見ていきます。 認証方法として当然とされているパスワード認証ですが、以下の 3 つの課題を持っています。 ① パスワードの使い回し ② 推測されやすいパスワードの使用 ③ フィッシングアプリへのパスワード入力 それぞれ見ていきましょう。 ① パスワードの使い回し ログインが必要なアプリにはそれぞれ異なるパスワードを使用するというのは皆さんご存知だとは思います。 とはい

    Auth0にPassKeyが搭載されたぞ!!!
  • パスキーに入門してみた話 - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 久しぶりの投稿です。 はじめに 昨今、様々なサイトがどんどんパスキーに対応しはじめてきました。 まだまだパスキーがデフォルトになっていくには時間が掛かりそうですが、どのような仕組みでパスキーを実装するのか、早めにキャッチアップしておくのも悪くないと思い、パスキーについて色々と調べてみました。 パスキーとは? パスワードの代わりに、自分の持つデバイスによる生体認証やパターンを用いて認証を行う方法のことです。 次世代認証技術であるFIDO(Fast IDentity Onlineの略で、「ファイド」と呼びます)を使った認証方式(詳細は後述)

    パスキーに入門してみた話 - Qiita
  • IAM Identity Center のロールで発行される一時認証情報をaws-sso-go 経由で 1Password に入れて利用する - 継続は力なり

    タダです. 以前の記事で 1Passowrd Shell Plugin を使って IAM アクセスキーとシークレットアクセスキーを保存して AWS CLI を使うのをやってみました.この記事では IAM Identicy Center(旧 AWS SSO) のロールで発行される一時認証情報を 1Password に入れたり更新ができたらローカルにクレデンシャルを残さずに使えてセキュアになるため,その検証を行ったのをまとめていきます. sadayoshi-tada.hatenablog.com IAM Identity Center のロールで発行される一時認証情報を保管する 保管したクレデンシャルを使って AWS CLI を実行する まとめ IAM Identity Center のロールで発行される一時認証情報を保管する IAM Identity Center と 1Password の

    IAM Identity Center のロールで発行される一時認証情報をaws-sso-go 経由で 1Password に入れて利用する - 継続は力なり
  • 新人の作ったWebアプリが穴だらけ!? ログイン画面に潜むセキュリティの”あるある”ワナ

    ネット上で商売するのが当たり前な時代。自社でWebサイトやWebアプリを抱える企業も相当な数になっている。そこでインシデントが発生すれば信用、ブランド、収益……失うものは計り知れない。 連載では情報セキュリティの専門家・徳丸浩さんが制作した脆弱性診断実習用のWebアプリ「BadTodo」を題材に、ストーリー形式でWebアプリ制作に潜む“ワナ”について学んでいく。 登場人物は全て架空の存在だが、ワナは全て現実にあり得るもの。せりふは徳丸さんの監修の下制作した。 特集:Webコンテンツの守り方 情報漏えい対策術 経営や企業イメージに大きな打撃を与える情報漏えい。近年ではWebサイトの改ざんやデータベースを狙った攻撃により情報を盗み出す事案が話題になっている。特集では情報漏えいを引き起こすサイバー攻撃と、WAFによる対策について解説する。 カクーノ株式会社:Webアプリ開発を手掛ける企業。

    新人の作ったWebアプリが穴だらけ!? ログイン画面に潜むセキュリティの”あるある”ワナ
  • モバイルとの相性最強と言われるgRPCをFlutter x NestJSで実装し、Stream通信や認証、複数言語実装に使えるか試す

    まとめ 相性バツグンといわれる、モバイル x gRPCは思ったよりずっと簡単に実装可能 複数言語間でもProtocol Buffersの恩恵により型変換を意識することなくスムーズに開発が進められる。 メソッド、引数の型、引数の返り値の型が自動生成されるのでとても良い RESTful APIにおけるheaderを、表現力の高いMetaDataとして利用し、認証認可等にも使えそう Streamをうまく使いこなせば、ユーザー体験をめっちゃ高くできそう。チャットやゲームなどの双方向通信が比較的楽に実装できるかも どんな人向きでない記事? NestJSの詳しい実装を知りたい方 Bidirectional streaming, Client streamの詳細実装を知りたい方 モバイル向け通信技術格的な選択肢、gRPCを実際に試してみたい 現在、私の働いているMinediaで開発しているサービス群

    モバイルとの相性最強と言われるgRPCをFlutter x NestJSで実装し、Stream通信や認証、複数言語実装に使えるか試す
  • RSA署名を正しく理解する

    初めに 「署名とはメッセージのハッシュ値を秘密鍵で暗号化したものであり、検証は署名を公開鍵で復号してハッシュ値と等しいかを確認することである」という説明(×)をよく見かけます。 正しい署名の定義と実際のRSA署名がどのようなものであり、上記説明(×)がなぜよくないのかを理解しましょう。 署名の定義 署名の解説は署名の概要でも解説しましたが、再掲します。 署名(方式)は鍵生成(KeyGen)、署名(Sign)、検証(Verify)の3個のアルゴリズムからなります。 KeyGenではアリスが署名鍵sと検証鍵Sを生成します。署名鍵sは自分だけの秘密の値なので秘密鍵、検証鍵Sは他人に渡して使ってもらう鍵なので公開鍵ともいいます。 Signは署名したいデータmに対して署名鍵sを使って署名と呼ばれるデータσを作ります。 データmと署名σのペアを他人(ボブ)に渡します。 Verifyはボブが検証鍵Sを使

    RSA署名を正しく理解する








ApplySandwichStrip

pFad - (p)hone/(F)rame/(a)nonymizer/(d)eclutterfier!      Saves Data!


--- a PPN by Garber Painting Akron. With Image Size Reduction included!

Fetched URL: http://b.hatena.ne.jp/latteru/%E8%AA%8D%E8%A8%BC/

Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy