はじめに はじめまして！レバテック開発部でレバテックプラットフォーム開発チームに所属している塚原です。 直近に認証・認可周りの改修を予定しているため、チーム内で認証・認可の基礎からOAuth・OpenID Connectの仕組みを学ぶ勉強会を実施しました。今回はそこで学んだことのうち、認証・認可の基礎とOAuthの仕組みをまとめます。また、WebフレームワークとしてHono、JavaScriptランタイムとしてBunを使って、OAuthクライアントを実装してみます。 対象読者 認証と認可の違いってなんだっけ...?という人 Basic認証やDigest認証てなんだっけ...?という人 OAuthはライブラリ使って実装してるから仕組みよくわかっていない...という人 OAuthのクライアントの実装って何をすればいいんだっけ...?という人 認証・認可の基礎 2024/7/18 追記 こちらで

ritouです。 タイトルに全部書きましたが、Xでharuyamaさんが書かれていたものです。 (広義の公開鍵暗号の)電子署名の文脈においては公開鍵/秘密鍵と言わないで署名鍵/検証鍵などと言ったほうがいいのではないかな— HARUYAMA Seigo (@haruyama) 2024年5月19日 よくある誤解 最近、公開鍵暗号方式がデジタル署名文脈で使われているユースケースに触れる機会が増えてきました。 自分の守備範囲でいうと OpenID ConnectのIDToken パスキーのAttestation/Assertion 雰囲気で使われているJWT認証() あたりでしょうか。 もちろん暗号化/復号のユースケースもあるにはあるのですが、自分の観測範囲ではデジタル署名文脈の方が圧倒的に多く使われています。 このあたりを解説しようとする記事において、誤解というか誤った認識をされがちなのが、

TL;DR 技術記事を書いて公開してくれる人は貴重な資源なので、なるべく潰さないように大事にしましょう。 はじめに プログラムを書いてて、なにかわからないことがあれば検索すると思います。すると、世の中にはごく少数の役に立つ記事と、大多数の役に立たない記事があることがわかるでしょう。その役に立つ記事を求めてネットの海をさまよっていると、「あれ？またこの人の記事だ」と思うことがよくあるでしょう。C++の言語仕様を調べてると「あの人」の、Vim関連を調べていると「あの人」の、Go言語なら「あの人」の記事を見つけることでしょう。逆に言えば、ある程度限定された分野において、体系だった知識があり、わかりやすい記事を書いてくれる人というのは極めて貴重な人材ということになります。 しかし、そんな「つよつよエンジニア」も、はじめから強かったわけではありません。当然のことながら新人時代があり、よくわかっていな

ritou です。 大きなサービスで何か問題があると、それをきっかけに皆さんのセキュリティ意識が高まりかけたりするものです。 最近はパスワードマネージャーやパスキーについて言及する人も増えてきました。 表題の通り、パスワードマネージャーをお勧めしますという話を書きます。新しい話ではなく、いつもの内容です。 パスワード認証に求められる要件とは？ パスワード認証自体は脆弱な認証方式ではありません。 ユーザー、サービス共に要件を満たして実装、運用されているならば至高の認証方式なのであります。その要件を見てみましょう。 ユーザー 推測不可能な文字列にする 複数のサービスで別のパスワードを利用する 忘れない 第3者にパスワードを知らせない サービス パスワードを安全に管理する 各種攻撃からユーザーを保護する これに対する現状を見てみましょう。 "記憶する" パスワード認証の課題 ユーザー側が記憶で上

個人的に「Webサービスの公開前チェックリスト」を作っていたのですが、けっこう育ってきたので公開します。このリストは、過去に自分がミスしたときや、情報収集する中で「明日は我が身…」と思ったときなどに個人的にメモしてきたものをまとめた内容になります。 セキュリティ 認証に関わるCookieの属性 HttpOnly属性が設定されていること XSSの緩和策 SameSite属性がLaxもしくはStrictになっていること 主にCSRF対策のため。Laxの場合、GETリクエストで更新処理を行っているエンドポイントがないか合わせて確認 Secure属性が設定されていること HTTPS通信でのみCookieが送られるように Domain属性が適切に設定されていること サブドメインにもCookieが送られる設定の場合、他のサブドメインのサイトに脆弱性があるとそこからインシデントに繋がるリスクを理解してお

クラウド電話APIを手掛ける米Twilioは7月1日（現地時間）、セキュリティ保護されていないAPIのエンドポイントにより、“脅威アクター”（攻撃者）が同社の多要素認証ツール「Authy」のユーザーの多数の電話番号を入手したことを確認したと発表した。「このエンドポイントを保護する措置を講じ、認証されていないリクエストを許可しないようにした」という。 Twilioはユーザーに対し、Authyのアプリをすぐに最新版（Androidはv25.1.0、iOSはv26.1.0）にアップデートするよう呼び掛けている。 この件については6月27日、ShinyHuntersとして知られる攻撃者がダークウェブ上で、Twilioをハッキングして入手したという約3300万人のユーザーの電話番号を含むCSVファイルを公開した。米BleepingComputerは、このファイルにAuthyのアカウントIDや電話番号

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

安全なパスワードの設定・管理 企業・組織におけるパスワードは、ユーザ名と組み合わせることで企業・組織内の情報資産へのアクセスの可否を決める重要なものです。パスワードの重要性を再認識して、適切なパスワード管理を心がけましょう。 他人に自分のユーザアカウントを不正に利用されないようにするには、推測されにくい安全なパスワードを作成し、他人の目に触れないよう適切な方法で保管することが大切です。 安全なパスワードの設定 安全なパスワードとは、他人に推測されにくく、ツールなどの機械的な処理で割り出しにくいものを言います。 理想的には、ある程度長いランダムな英数字の並びが好ましいですが、覚えなければならないパスワードの場合は、英語でも日本語（ローマ字）でもよいので無関係な（文章にならない）複数の単語をつなげたり、その間に数字列を挟んだりしたものであれば、推測されにくく、覚えやすいパスワードを作ることがで

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の開発を始めました。その過程で

ritouです。 「宣伝」2024/05/16(木)にOpenID TechNight vol.21 ~ Shared Signal Framework(SSF)+αの勉強会が開かれるようです。 openid.connpass.com そもそもSSFって知ってます？勉強会までにSSFについて少し予習しておきましょう。 SSFについて Tom Satoさんには1月のOpenID Summit Tokyo 2024にてSSFについて講演していただきました。 www.youtube.com また、昨年末のアドベントカレンダーでも記事を書いていただきました。 zenn.dev RISCとCAEPをざっくり整理すると、 RISC : アカウントに関するイベント送信を送信 (IdPでユーザーが退会した、BANされた、乗っ取られた、メアド変更した時などに連携しているサービスに通知) CAEP : セッシ

いやいや"サーヒス"て。 昨年からパスキーが話題になっていますが、地主と小作人とばかりに、サービスが認証方式をサポートしなければユーザーはそれを利用できないわけです。 サービス側がパスキーにどう向き合うのか、についてはZennに記事を書きました。こっちはいいですよね？ 書くのを忘れていたユーザー側ですが、これまでの啓蒙はこんな感じでした。 複雑で推測不可能(略...、使い回しをやめましょう : パスワード認証を正しく使え！いやそれができないからこうなっとるんや TOTPのような2FAが利用できるサービスでは利用しましょう : どうせ推測可能なパスワード使い回すんだろ。それなら別の認証方式で何とかしろや そして、パスキー対応サービスが出てきたらパスキー使えよというのが追加されましたnew!って感じですが、いきなりそう言われてもパスキーって何だよd何とかはくっそ評判悪いんだが大丈夫なのかこれっ

こんにちは。デジカルチームの末永(asmsuechan)です。この記事は「フルスクラッチして理解するOpenID Connect」の4記事目です。前回はこちら。 www.m3tech.blog 13 state の実装 14 nonce の実装 15 まとめ 16 参考 Wre're hiring! 今回は全4回中の第4回目です。 (1) 認可エンドポイント編 (2) トークンエンドポイント編 (3) JWT編 (4) stateとnonce編 13 state の実装 https://openid-foundation-japan.github.io/rfc6819.ja.html#anchor15 https://openid-foundation-japan.github.io/rfc6749.ja.html#CSRF state は OAuth 由来の仕様です。つまりアクセストーク

(4/14 表記揺れなどのコメントいただいたので、少し修正、追記しました。) ritouです。 私のタイムラインによく出てくる、この辺りの話っていつになってもしっくりこない人が多いと思います。 OAuth認証👮 : アプリケーションがユーザー情報取得を提供するAPIを叩いて受け取ったユーザー識別子を使って新規登録やログインさせてはいけない。OIDCのIDTokenを使え ユーザーIDが取得できればログインさせていいのではないか IDTokenはユーザーIDを含むJWTだが、どうしてこれは良いのか デジタル庁が進めるマイナンバーカードを用いた個人向け認証アプリケーション(以下、認証スーパーアプリ)の用途 マイナンバーカードを用いた本人確認は既にいくつかの民間サービスで使われているが、ログインに使えるとはどういう事なのか デジタル庁からは スマホ用電子証明書搭載サービス　という物も出ているが

ritouです。 こちらの記事の続きです。 前回の記事の振り返り 3行でまとめると まずは単一アプリケーションのID管理について解像度を上げてみよう Webアプリケーションフレームワークを使って新規登録から退会までざっくり動作確認してから、色々いじったり調べてみるのが良いよ セキュリティ関連の機能とか、新規登録時の身元確認、ログイン方法を拡張してみよう といったところです。個人的にはこれは全エンジニア向けの研修であってもいいぐらいのものだと思います。 今回の内容 タイトルにある通り、複数のアプリケーションが関わる部分に入っていきましょう。 というか、OAuthとOIDCやりたいんですよね？え?SAML? まずはID連携のベーシックな部分に触れていきましょう。 プロトコルは混ざっちゃっていますが、順番としてはこんなのはどうでしょう。 OAuth 2.0のClientとしての機能を設計/実装す

モニクル社内3分LTで発表しました。技術職以外の人向けに話したので、抽象度高めにしてあります。

ritou です。 これについての話です。 この辺りずっとやってると「認証認可について詳しくなりたいです！」「OIDCに興味があります！」みたいなところから「何をやればいいですか！？」みたいなことを聞かれたりします。(やりたいことやればいいじゃんと思いつつ) 昔は 年に一回ぐらいIdPを作りましょう なんて言っていた時期がありますが、まぁそう簡単にできるものでもありません。ふじえさんの記事をdisっているわけではないですが、OIDCのところから始めても他にやることが多すぎて結構つらいのです。 何から始めたら良いか 現状のおすすめとしては、 Webアプリケーションフレームワークを使って単一アプリケーションを動かして、既存コードを追ったり拡張できるならやってみて色々細かい部分を理解するところから始めましょうというところです。 なんと、ひと昔前にQiitaに溢れたようなやり方ですが どのフレーム

こんにちは。デジカルチームの末永(asmsuechan)です。 この記事では、OpenID Connect の ID Provider を標準ライブラリ縛りでフルスクラッチすることで OpenID Connect の仕様を理解することを目指します。実装言語は TypeScript です。 記事のボリュームを減らすため、OpenID Connect の全ての仕様を網羅した実装はせず、よく使われる一部の仕様のみをピックアップして実装します。この記事は全4回中の第1回となります。 なお、ここで実装する ID Provider は弊社内で使われているものではなく、筆者が趣味として作ったものです。ですので本番環境で使用されることを想定したものではありません。なんなら私は ID Provider を運用する仕事もしておりません。 1 OAuth 2.0 と OpenID Connect 1.1 用語の

パスキー対応 という記事を見ると フィッシング耐性があるパスワードレスな世界が来る！ と期待を抱き、冷静に考えて パスワードが残ってるうちはリスクは残ってるしフィッシングにもやられるし何にもかわらねぇじゃねーか と遠い目をしてしまう皆さん、こんにちは。 ritou です。 いきなり一気に進むわけがないだろ。ということで、認証を必要とするサービスもユーザーも、パスキーにより理想的な状態となるまでには段階というものがあり、 大人の階段と同じで やるべきことがあります。そのあたりを理解することで、一喜一憂せずにやっていきましょう。 ２つの段階 既存の認証方式に加えてパスキーによる認証が利用可能 : 過渡期ってやつでしょうか。イマココ パスキーのみが利用可能 : 我々が望んでいる世界や！ あとはその前の なんもしてない段階 です。 そんなに新しい話でもないでしょう。 段階を進めるために必要な対応

はじめに パスワードは古来より認証に良く使われる方法ですが、その運用の難しさからセキュリティの懸念とその対策としての運用の複雑さ（複雑で長い文字列、90日でパスワード変更など）が要求される大きく問題をもった仕組みです。 その根本的な解決策としてFIDO Allianceを中心に推進されている 「パスワードレス」 が注目されています。これはPINや生体認証とデバイス認証を使ったMFAからなっており、フィッシングやパスワード流出に強い上に、ユーザも複雑なパスワードを覚えなくて良い、という大きなメリットがあります。最近はこの流れでPassKeyというものが登場し、Apple/MS/Googleのプラットフォーマが対応したことで、本格運用に乗せれるフェーズになってきました。というわけで以下に解説動画を作ったのですが、動画中で時間の都合で触れきれなかったところや、JavaScriptによる実装のサン