タグ

jwtに関するteitei_tkのブックマーク (16)

  • JWTセキュリティ入門

    SECCON Beginners Live 2023「JWTセキュリティ入門」の発表資料です。

    JWTセキュリティ入門
  • "JWT=ステートレス"から一歩踏み出すための考え方

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

    "JWT=ステートレス"から一歩踏み出すための考え方
  • Microservices における認証と認可の設計パターン

    マイクロサービスにおける認証と認可の、一般論としての設計パターンを調べたところ、Web 上の複数の記事で似たようなパターンが登場していた。ここでは、まず認証と認可が実現したい一般的な要件と、そのマイクロサービスでの難しさを整理し、認証と認可に分けて調査したパターンをまとめた。 あくまで “一般論” なので、実際には個々のドメインにあわせてアレンジが必要 往々にしてこの “アレンジ” に価値が宿るものだが、まずはセオリーを知っておきたいというモチベーションで調査した Web 上の記事を読んでまとめただけなので、手を動かしての確認はしておらず、理解が甘い部分はご容赦ください 具体的な通信方式やサービス間通信のセキュリティといった具体論までは踏み込めていない。このへんはサービスメッシュやゼロトラストネットワークといったトピックが登場すると思われる これらは次回以降の Todo としています その

    Microservices における認証と認可の設計パターン
  • セキュリティ視点からの JWT 入門 - blog of morioka12

    こんにちは、ISC 1年 IPFactory 所属の morioka12 です。 この記事は IPFactory Advent Calendar 2020 の10日目の分になります。 IPFactory という技術サークルについては、こちらを参照ください。 記事の最後に記載されている余談でも IPFactory の詳細を紹介しています。 はてなブログに投稿しました #はてなブログ IPFactory Advent Calendar 2020 の10日目の記事を書きました#JWT #security セキュリティ視点からの JWT 入門 - blog of morioka12https://t.co/g1MYe77hAF — morioka12 (@scgajge12) 2020年12月10日 普段は Web Security や Cloud Security 、バグバウンティなどを興味分

    セキュリティ視点からの JWT 入門 - blog of morioka12
  • Hardcoded secrets, unverified tokens, and other common JWT mistakes

  • JSON Web Token (JWT)

    JSON Web Token (JWT) draft-ietf-oauth-json-web-token-11 Abstract JSON Web Token (JWT) は2者間でやりとりされるコンパクトで URL-safe なクレームの表現方法である. JWT に含まれるクレームは JavaScript Object Notation (JSON) オブジェクトとしてエンコードされ, JSON Web Signature (JWS) のペイロードや JSON Web Encryption (JWE) の平文として利用される. JWS や JWE とともに用いることで, クレームに対してデジタル署名や MAC を付与と暗号化の両方を行うことが可能となる. JWT の推奨される発音は, 英単語の "jot" と同じである. Status of this Memo This Internet

  • GitHubと連携する新しいアプリの形:GitHub Appsの作り方 - Qiita

    GitHub Appsとは、GitHubと連携するアプリケーションの新しい形式です。 この形式はアプリケーションのマーケットプレイスである、GitHub Marketplaceの公開と共にアナウンスされました。つまり、GitHub Appsを作成する、マーケットプレイスで公開する、それで収益を上げる、というエコシステムがしっかりと整備されたということです。 そんな夢の広がるGitHub Appsの作り方を、記事では紹介しようと思います。 GitHubと連携するアプリケーションの形式 まず、GitHub Appsを含め、GitHubと連携するアプリケーションの形式を整理しておきます。 Webhooks Webhooksは、リポジトリの特定のイベント(pushしたとか)をトリガにして、その更新情報を設定先のサーバーなどに通知する形式になります。設定は以下の場所で行います。ここで、通知対象のイ

    GitHubと連携する新しいアプリの形:GitHub Appsの作り方 - Qiita
  • Webアプリケーションのセッション管理にJWT導入を検討する際の考え方 - r-weblife

    おはようございます、ritou です。 qiita.com これの初日です。 なんの話か 皆さんは今まで、こんな記事を目にしたことがありませんか? Cookie vs JWT 認証に JWT を利用するのってどうなの? JWT をセッション管理に使うべきではない! リンク貼るのは省略しますが、年に何度か見かける記事です。 個人的にこの話題の原点は最近 IDaaS(Identity as a Service) として注目を集めている Auth0Cookie vs Token とか言う比較記事を書いたことだと思っていますが、今探したところ記事は削除されたのか最近の記事にリダイレクトされてるようなのでもうよくわからん。 なのでそれはおいといて、この話題を扱う記事は クライアントでのセッション管理 : HTTP Cookie vs WebStorage(LocalStorage / Sess

    Webアプリケーションのセッション管理にJWT導入を検討する際の考え方 - r-weblife
  • 作って学ぶ GitHub Apps|teitei.tk

    今回はGitHub Appsについて調べて実際にサンプルアプリを登録、アクセストークンの発行&APIの実行までを試してみました。 そもそもGitHub Appsとは IIJさんの記事が分かりやすかったので引用。 GithubではGithubと連携するツールを作るための仕組みとして、Personal access tokens を使う方法と、OAuthを利用する方法がありました。しかしいずれの仕組みもユーザーに紐付いたアクセスキーが発行されてしまうため、設定したユーザーが退職したり、異動したりしてアカウントが停止されたりするとアクセスキーも無効になり、API連携がエラーになってしまうことがあります。 そこで新しくGithub Appsという仕組みが導入され、リポジトリに紐づけて各種アプリケーションにアクセスを許可できるようになりました。今後はGithub Appsを用いて連携するのが推奨され

    作って学ぶ GitHub Apps|teitei.tk
    teitei_tk
    teitei_tk 2019/10/28
    書いたぞ。
  • RS256 と HS256 ってなにが違うの - Qiita

    どちらの選択肢も、IDプロバイダがJWTに署名する(sign)ために使用するアルゴリズムです。ここで「署名する」とは、トークンの受信者が、トークンが改ざんされていないことを検証できる「署名(signature)」(JWTの一部)を生成する暗号操作です。 RS256は非対称アルゴリズムであり、公開鍵/秘密鍵のペアを使用します。IDプロバイダは署名を生成するために使用される秘密鍵を持ち、JWTのコンシューマは署名を検証するための公開鍵を取得します。秘密鍵とは対照的に、公開鍵は保護されている必要がないため、ほとんどのIDプロバイダは、IDのコンシューマが(通常はメタデータURLを介して)入手して使用できるようにします。 一方、HS256は、対称アルゴリズムであり、2つの当事者間で共有される1つの(秘密)鍵のみを使用します。署名を生成して検証するために同じ鍵が使用されるので、鍵が侵害されていないこ

    RS256 と HS256 ってなにが違うの - Qiita
  • Rails 5.2でJWTとdeviseを使った認証の仕組みを作る - production.log

    概要 最近フロントエンドからAPIを叩く実装における認証の仕組みをどうするか考えていました。 以前、AWS Cognitoを使った認証仕組みを作ったことはあったのですが、Railsの場合はどのようにJWTを扱うか知りたかったので、作ってみました。 今回は、タイトルの通りRails 5.2でJWTとdeviseを使った認証の仕組みについて解説します。*1 概要 想定しているケース 調査したこと JWTを扱うための仕組みがdeviseにあるか? なければ、それを補うためのgemがあるのか? ユーザーがブラウザからメール / パスワードを入力してユーザー登録 トークンの取得、検証処理の追加 動作確認 トークンの取得 トークンを使ってAPI実行 まとめ 想定しているケース 想定しているケースはシンプルです。 ユーザーの動き的には、こんなことをすることを想定しています。 ユーザーがブラウザからメール

    Rails 5.2でJWTとdeviseを使った認証の仕組みを作る - production.log
  • JSON Web Tokenを完全に理解する - Qiita

    Help us understand the problem. What are the problem?

    JSON Web Tokenを完全に理解する - Qiita
  • RFC 7519: JSON Web Token (JWT)

    [RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Errata] [Info page] PROPOSED STANDARD Updated by: 7797, 8725 Errata ExistInternet Engineering Task Force (IETF) M. Jones Request for Comments: 7519 Microsoft Category: Standards Track J. Bradley ISSN: 2070-1721 Ping Identity N. Sakimura NRI May 2015 JSON Web Token (JWT) Abstract JSON Web Token (JWT) is a compact, URL-safe means of representing claims to

  • JWT authentication: Best practices and when to use it - LogRocket Blog

    Editor’s note: This JWT authentication tutorial was last updated on 5 December 2023 to discuss some of the inefficiencies of JWT authentication, including token invalidation and size constraints. Ensuring the security of user data and establishing secure communication between servers and clients is a critical aspect of web development. Various tools and packages have been developed to facilitate t

    JWT authentication: Best practices and when to use it - LogRocket Blog
  • 【JWT】 入門 - Qiita

    JWTとは 公式サイト JSON Web Tokenの略 電子署名により、改ざん検知できる。 認証用のトークンなどで用いられる。 構成 ヘッダ、ペイロード、署名の3つから成る。 それぞれは、Base64でエンコードされている それぞれは、 . (ドット) で結合されている。

    【JWT】 入門 - Qiita
  • JOSE(JavaScriptオブジェクトへの署名と暗号化)は、絶対に避けるべき悪い標準規格である | POSTD

    注: 稿は元はJSON Web Tokens(JWT)について書いたものですが、JWTはJavascript Object Signing and Encryption(JOSE)のサブセットであるため、以下の批評はどちらかというとJOSE全体に焦点を当てています。 もし既にJavascript Object Signing and Encryption(JOSE)を実装することを決めているなら、それがJSON Web Tokens、JSON Web Encryption(JWE)、JSON Web Signatures(JWS)のいずれであっても、その決断に疑問を持つべきです。間違いを犯そうとしている可能性があります。 この投稿に書いたことはすべて、RFC 7519、RFC 7515、そしてRFC 7516に則っています。将来、新規のRFCでは以下に挙げるような欠陥はなくなっている可能

    JOSE(JavaScriptオブジェクトへの署名と暗号化)は、絶対に避けるべき悪い標準規格である | POSTD
  • 1