タグ

ブックマーク / zenn.dev/ritou (5)

  • "JWT=ステートレス"から一歩踏み出すための考え方

    おはようございます、ritouです。 この話に乗っかっていきます。 3行で ログアウト時にJWTを無効化できない実装は今後脆弱性診断で「OWASP Top 10 2021違反」と指摘されるようになりそう(今も個別にされてるかもしれないけど) JWTは単純なフォーマットなので、ステートレスなセッション管理においてログアウトしたときに文字列自体を無効化できない件は独自エンコード方式(一般的にフレームワークのCookieストアと呼ばれているもの)でも起こり得る 「セッションID vs JWTで内包」 以外にも 「セッションIDをJWTに内包」もあり得る。既存の機能を残しつつ「JWTで武装」する選択肢も考えてみてはどうか。 ステートレスなセッション管理でログアウトの際に文字列自体を無効化できない問題 これは前から言われていますし、駆け出し何とか勢のQiita記事に書かれるぐらいには一般的です。 2

    "JWT=ステートレス"から一歩踏み出すための考え方
  • デジタル認証アプリとのID連携で使われている標準化仕様と勘所

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

    デジタル認証アプリとのID連携で使われている標準化仕様と勘所
    enemyoffreedom
    enemyoffreedom 2024/06/24
    「"お前らが言う本人確認 is 何?" については、身元確認 と 当人認証 の両方が可能です。そして、それら両方を実現するためのID連携として、OpenID Connect(以下、OIDC)が採用されています」
  • パスキーとID連携の認証フローの共通点から見る認証技術の基本

    ritou です。 少し前にパスキーとID連携の関係を考えるときにこういう観点があるよという話をしずかな方に書きました。 今回は、ログインに利用しようとした時のフローの中でここ似ているよね、こんな意図があるんだよっていう部分を取り上げます。 認証フローの似ている点 登場人物をUserAgent、RP、Authenticatorとして、あらゆるところを簡略化したシーケンスを用意しました。 ID連携、いわゆるソーシャルログインでは次のようになります。 登場人物をUserAgent、RP、IdPとするとこんな感じでしょう。 もちろん細かいところは違うわけですが、全体の流れは似ています。 WebAuthnのchallenge, OIDCのnonce, state 先ほどのシーケンス、たまたま似ていると言うよりも、これは認証フローにおける基の流れであると意識しておきましょう。 パスキーやID連携の

    パスキーとID連携の認証フローの共通点から見る認証技術の基本
  • パスキー時代の"認証要素"の考え方 ~パスキーとパスワードマネージャー~

    ritouです。 サービス、ブラウザ、OSそれぞれのパスキー対応が日々進んでいます。 その中で、パスキーを利用してみて認証要素についてふと考えてしまう人がいるでしょう。 パスキー簡単!けどこれ指紋認証だけ?弱くなってない? SMS OTPを2FAに設定し、パスワードマネージャーも使ってたから使い勝手はあまり変わらない。むしろSMS OTPがないぶんだけ弱くなった? この辺りについて整理します。 認証要素というと、次の3つです。 SYK: Something You Know. パスワード、PIN SYH: Something You Have. 認証アプリ、TOTP生成アプリ、バックアップコード、 SYA: Something You Are. 生体認証 前にこんな記事を書きました。 この内容を説明すると、「うん、わかってる」って人は多いです。 でも、実際に使ってみると心許なく感じたりする

    パスキー時代の"認証要素"の考え方 ~パスキーとパスワードマネージャー~
  • GitHubのパスキー/Passkey対応を試してみた

    こんばんは、ritouです。 今回はこれを試してみます。 まずはパスキーを有効にします。 PCの画面だと右上のプロフィール画像をクリックするとワーっと出てくる中の "Feature preview" ですね。 "Passkeys" のところを選んで こう! (Enable) で、右に表示されている "Add a Passkey" を押してもこれ ただの画像なので何も起こらないですよ。 物は "Settings" -> "Password and authentication" と進めばあります。 2FAで使っていたPasskeyの昇格 追加してみようと思うと、再認証が必要...わかります。 そういえば自分は2FAで既にHybrid Transportを使ってAndroidのPasskeyを利用していました。 とりあえずそっちで再認証を終わると... ・・・おや!? 2FA用のPasske

    GitHubのパスキー/Passkey対応を試してみた
  • 1