2025年8月1日に開催された、JANOG56 Meeting 野良LT BoFの発表資料です。

本記事では「JWTベースの認証・認可」という表現を使用しています。 認証(Authentication):ユーザーの本人確認(ログイン時のID/パスワード検証) 認可(Authorization):リソースへのアクセス権限の確認(JWTによる権限検証) JWTは主に認可の仕組みとして機能しますが、認証から認可までの一連のシステムを指して「JWTベースの認証・認可」と表現しています。 1.1 JWTの登場背景と従来の認証方式の課題 従来のWebアプリケーションでは、「セッション・Cookie認証」が認証方式の主流でした。これは、サーバー側でユーザーの認証状態をセッションとして管理する方式です。 セッション・Cookie認証の基本的な流れ ユーザーがログインすると、サーバーはセッションIDを発行します。 サーバーは、そのセッションIDとユーザー情報を紐付けて自身のストレージ(セッションストレー
はじめに こんにちは、GMO Flatt Security株式会社 セキュリティエンジニアの小武です。 近年、WebAuthn、特にPasskeyはパスワードレス認証への関心の高まりや利便性の高さから、普及が進んでいます。 WebAuthnによるPasskey認証は強固な認証手段ですが、複雑な認証基盤の実装に不備があると、依然としてアカウント乗っ取りを含む従来のセキュリティリスクを払拭できません。 本記事では、W3CのWorking Draft(2025年5月現在)である Web Authentication: An API for accessing Public Key Credentials Level 3 を読み解き、Relying Party(RP)としてPasskey認証を導入する際に実装で注意すべき点を説明いたします。 はじめに Passkey認証でも生まれ得るセキュリティリ
「Google Workspace」に接続する際、「CalDAV」「CardDAV」「IMAP」「POP」といった古いプロトコルを今も使っていないだろうか。そのような場合は、できるだけ早くアカウント設定を変更することをお勧めする。 米国時間9月30日から適用された変更によって、Google Workspaceはこれらの古いプロトコルをサポートしなくなった。また、「Google Sync」を介した接続もできなくなる。その結果、「パスワードのみを使用してGoogleアカウントにアクセスするサードパーティーアプリ」は遮断されると、Googleは警告している。 そこで、ユーザーを保護するためにサポートが打ち切られることになったわけだが、古いサービスをまだ使っているユーザーは、Googleアカウントにアクセスできなくなる。 これらのプロトコルに代わって、Googleがユーザーに勧めているのは、セキュ
タイトルの通りなんですが、その昔これを見つけた時はヘンな汗が噴き出ましたよ。 eapol_testを使ったEAP-TLS認証 SUCCESS... (;゚∀゚) 自分はEAP-TLSを使わないからといっても、デフォルトで穴が開くので要注意です。 不具合の内容 以下の条件がすべて満たされているとき、同一CAが発行・署名したクライアント証明書を用いて、第三者によるEAP-TLS認証が成功します。無線LANに不正に接続できたりします。 FreeRADIUSでPEAP, EAP-TTLSなどを使っている。 Public CAから発行されたサーバ証明書を使っている (Let's EncryptでもUPKIでも、何でもよい) EAP-TLSを運用していないのに、その機能が無効になっていない (FreeRADIUSのデフォルト)。 FreeRADIUSの設定ファイル mods-enabled/eap の
2024年6月21日にデジタル庁からデジタル認証アプリの発表がありました。 このデジタル認証アプリで何ができるのか、ざっくり整理してみました。 この記事で対象としている方 デジタル認証アプリの概要についてざっくり理解したい方 デジタル認証アプリについて今北産業してほしい方 この記事では技術的な話はなるべく避け、全体像を整理していきます。 技術的な話を理解したい方は、参考リンクより他の方が書かれた記事を参照してみてください。 「デジタル認証アプリ」はどんなものか? 「デジタル認証アプリ」は、マイナンバーカードを使った認証や署名を、安全に・簡単にするための、デジタル庁が提供するアプリです。 (デジタル認証アプリサービスサイトより引用) デジタル認証アプリは、デジタル庁が提供するデジタル認証アプリサービスAPIと組み合わせて1つのサービス(デジタル認証アプリサービス)を構成しています。デジタル認
モニクル社内3分LTで発表しました。技術職以外の人向けに話したので、抽象度高めにしてあります。
こんにちは。デジカルチームの末永(asmsuechan)です。 この記事では、OpenID Connect の ID Provider を標準ライブラリ縛りでフルスクラッチすることで OpenID Connect の仕様を理解することを目指します。実装言語は TypeScript です。 記事のボリュームを減らすため、OpenID Connect の全ての仕様を網羅した実装はせず、よく使われる一部の仕様のみをピックアップして実装します。この記事は全4回中の第1回となります。 なお、ここで実装する ID Provider は弊社内で使われているものではなく、筆者が趣味として作ったものです。ですので本番環境で使用されることを想定したものではありません。なんなら私は ID Provider を運用する仕事もしておりません。 1 OAuth 2.0 と OpenID Connect 1.1 用語の
これは、豆蔵デベロッパーサイトアドベントカレンダー2022第8日目の記事です。 JSON Web Token(JWT)の単語を目にすることがよくあると思いますが、それと一緒に認証と認可や、RSAの署名や暗号化、そしてOpenIDConnectやOAuth2.0までと難しそうな用語とセットで説明されることも多いため、JWTって難しいなぁと思われがちです。しかし、JWT自体はシンプルで分かりやすいものです。そこで今回は素のJWTの説明からJWS、そしてJWT(JWS)を使った認証を段階的に説明していきます。 おな、この記事はJWT全体の仕組みや使い方の理解を目的としているため、以下の説明は行いません。 RSAやHMACなど暗号化やアルゴリズムの細かい説明 JWTを暗号化するJWEとJSONの暗号鍵表現のJWKについて OpenIDConnectとOAuth2.0について 記事は上記のような内容
症状検索エンジン「ユビー」 では、ローンチ当初から Firebase Auth (GCP Identity Platform) を使っていましたが、OIDCに準拠した内製の認証認可基盤に移行しました。 認証認可基盤そのものは m_mizutani と nerocrux と toshi0607(退職済) が作ってくれたため、僕は移行のみを担当しました。 結果として、強制ログアウトなし・無停止でビジネス影響を出さずに、年間1000万円以上のコスト削減に成功しました[1]。その移行プロセスについて紹介します。認証認可基盤そのものの紹介はあまりしません。 移行した理由 大量の匿名アカウント ユビーでは、アクセスした全ユーザーに対して自動的に匿名アカウントを発行しています。これにより、ユーザーがアカウント登録しているかどうかに関わらず、同じID体系で透過的に履歴情報等を扱うことができます。アカウント
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 暗号技術のなかでも、公開鍵暗号(広義)に分類されるものとして、電子署名があります。 これは、PKI ( 認証局、SSL/TLS証明書、…etc. ) という文脈で説明されているのは見かけるのですが、何者であるかを証明する「認証」という役割での説明は、なかなか見ないように思います。 ということで今回、認証に絞って説明ができないかどうか、試みとして書いてみようと思います。 なお、前提知識として電子署名の基礎知識に目を通しておくことをお勧めします。 電子署名による認証へのアプローチ 認証とは? 電子署名を認証(身分証明)に使うという
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事について Webアプリのアクセス制御を行いたい!となったときに学ぶべきなのは認証・認可の仕組みです。 AWSにはAmazon Cognitoというユーザー管理を行うための仕組みが存在し、これを利用すれば「実装するだけなら」簡単にアプリのアクセス制御を行うことができます。 この記事では「Cognitoが実際に何をやってくれているのか?」というところまで掘り下げながら、簡単なReactアプリを作っていきます。 アジェンダ Cognitoのユーザープールを作って触ってみる Reactアプリに認証の仕組みを入れてみる Cognitoで認
こんにちは。エムスリー・QLife(エムスリーのグループ会社)・エムスリーヘルスデザイン(エムスリーのグループ会社)でエンジニアとして各種作業に関わっている山本です! 以前もメール送信の話を書かせていただいたことがありますが、今回もまたメールネタとなります。今回のお題はメールセキュリティです。 大量メール送信のための予備知識 - エムスリーテックブログ すでにご覧になった方もいるかと思いますが、次のようなニュースが流れています。 www.proofpoint.com この「GoogleとYahooの新Eメール認証要件」ってつまりどういうことよ? というところを具体的にどのように進めているかについて書かせていただきたいと思います。 2023/12/18追記 : Googleからメール送信にTLSを使うことが追加要件として示されました。 TL;DR とりあえず何から始める? 何はともあれ実際に
免責事項 社内向けに展開するように雑にまとめました Next.jsの知見が深くない人がリードしてPoCを立ち上げなきゃいけなくなったが、社内的にはNext.jsを推奨しているみたいな場面を想定しています なので自信ないところも多いですが割と断言するように心がけて書いています PoCの立ち上げ想定なので、jest/Storybookなど内部品質面についてあまり深く書くことを避けています ほぼ自分の知識だけで書いており私見も多いですし、そもそも自分自身がトップクラスの知識や視座を有しているわけでもないので、まずは以下の話を理解はした上で、踏襲するかどうかは別途他記事やGitHub、公式ドキュメントなどを漁って判断することを推奨 App RouterかPages Routerか 2023年末現在まだApp Routerは技術記事が足りてきている印象ではないため、社内でノウハウを積極的に貯めていく
SPAやモバイルアプリから利用するAPIを開発する際の、トークン認証のお話です。 どの認証ライブラリを使うべきという話ではなく、トークン認証の論理的な設計について考察します。 私自身も結論が出ていないので、色んな意見が聞けると嬉しいです。 出発点 ユーザテーブルにアクセストークンを持つのが最も安直な発想だと思います。 ログイン成功時にアクセストークンを発行し、該当ユーザレコードにセット。 同時に有効期限もセットします。 認証時には、アクセストークンが存在し有効期限内であれば、認証を通過させ、 そうでなければ認証失敗とします。 ログアウト時には、該当ユーザレコードのアクセストークンを空にします。 発行日時を持ち、システム内に定義された有効期間をもとに、認証時に計算する方法もあると思います。 Laravel Sanctum 等はそういう実装です(しかもデフォルトでは有効期限なし)。 有効かどう
クラウドソフトウェアの認証やセキュリティに関するさまざまなソフトウェア開発を行うOryは2023年7月13日、同社が開発するオープンソースのユーザ認証、管理システムであるOry Kratosのv1.0.0をリリースした。 Ory Kratos https://github.com/ory/kratos Ory KratosはAPIベースのID/ユーザ管理システム。セルフサービスのログインと登録、多要素認証(MFA/2FA)、アカウント検証、アカウント回復など、ほとんどすべてのアプリケーションが対応する必要のある一般的な機能が実装されている。APIのみのヘッドレスであるため、開発者が自分でUIを構築する必要がある。またデータベース以外の外部依存関係がなく、さまざまなクラウド環境でのデプロイと拡張が簡単に行えるのが特徴。ほとんどのOS上でビルドできるほか、Linux、macOS、Windo
昔から、「OpenIDは認証でOAuthは認可だ」などということが言われます。しかし、その言語の意味を取り違えている方が結構多い気がしています。「もうOpenIDなんていらね。OAuthだけでいいじゃん」というような言説がよく流れてくるのがその証拠だと思います。OAuth認証というのもその類ですね。 そこで、今日はOAuthとOpenIDの違いを考えてみたいと思います。 OpenIDは紹介状、OAuthは合鍵 まずはOpenIDの概要の復習です。「OpenIDは認証」という言葉の内容をまずは復習してみましょう。 「認証」とは大変広い言葉でいろいろな場面で使われますが、「OpenIDは認証」という使い方の時は、「OpenIDは、いま来ている人の身元を認証」(ユーザ認証)という意味です。図にすると図1のような流れになります。 この例では、有栖さんがお客としてサービス提供をしているサイトである伊
「golang.tokyo」は、プログラミング言語のGoの導入企業のメンバーが集まり、Goの普及を推進するコミュニティです。ここで、フューチャー株式会社の渋川氏が登壇。GoでWebサービスを作る時の悩みから、認証リバースプロキシを作成した話を紹介します。 自己紹介 渋川よしき氏:フューチャー株式会社の渋川が発表します。まず「お前誰よ?」ですが、2017年からフューチャーで働いています。いろいろ本を書いています。『Real World HTTP』のほか、昔のものですが『つまみぐい勉強法』『Goならわかるシステムプログラミング』もあります。最近はよくJavaScriptというか、TypeScriptとGoとPythonを書いています。ほかに仕事でFlutterもやっています。 著書の『Real World HTTP』はちょこちょこ増刷もされています。買ってくれた方、ありがとうございます。実は今
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く