note のやらかしのあのへんについて。 認証自作、 Rails 、 Devise - Diary パーフェクト Rails 著者が解説する devise の現代的なユーザー認証のモデル構成について - joker1007’s diary 認証サーバーの実装は本質的に難しいです。セキュリティが絡むものは「簡単な実装」などなく、プロアマ個人法人問わず、個人情報を守るという点で、同じ水準を要求されます。悪意あるハッカーは常にカモを探していて、もし認証が破られた場合、自分だけではなく大多数に迷惑が掛かります。初心者だから免責されるといったこともありません。全員が同じ土俵に立たされています。 とはいえ、認証基盤を作らないといろんなサービスが成立しません。そういうときにどうするか。 Firebase Authentication で、タイトルの件なんですが、 Firebase Authenticat
認証と認可についての知識が必要になったので、基礎的なことを学んでいます。 一切何も知らない状態から手当たり次第に細かく調べるのは大変だったので、超サマリを整理してみようと思います。 この本は「個々の要素に詳しくなる必要はないんだけど、概要くらいはさっと把握しておきたい」とか「手当たり次第に詳細調査をする前に、一瞥してこれから踏み込もうとしている領域の超俯瞰マップを作る」という感じで使うことを想定しています。 同じ様な方の役に立ったら、とても嬉しいです。 この本は筆者の理解に連動して追記修正される可能性があります。
SPAのログイン周りについて、「これがベストプラクティスだ!」という情報があまり見当たらないので、様々な可能性を模索してみました。 いろいろな状況が想定され、今回記載する内容に考慮の漏れや不備などがありましたら是非コメントでご指摘いただきたいです!特に「おすすめ度:○」と記載しているものに対しての批判をどしどしお待ちしております! この記事でおすすめしているものであっても、ご自身の責任で十分な検討・検証の上で選択されてください。 前提 想定しているAPIは、 ログイン外のAPIにはPOST/PUT/DELETEのものがなく、GETのみ GETのAPIにはDBを更新するなどの操作がない とし、そのためログイン外ではCSRFを考慮しなくてよい、 という前提で話を進めます。 また、XSSに関しては常に対策は必要なのですが(フレームワーク側が自動的にしてくれる部分もある)、認証周りに関係すること以
マイクロサービスにおける認証と認可の、一般論としての設計パターンを調べたところ、Web 上の複数の記事で似たようなパターンが登場していた。ここでは、まず認証と認可が実現したい一般的な要件と、そのマイクロサービスでの難しさを整理し、認証と認可に分けて調査したパターンをまとめた。 あくまで “一般論” なので、実際には個々のドメインにあわせてアレンジが必要 往々にしてこの “アレンジ” に価値が宿るものだが、まずはセオリーを知っておきたいというモチベーションで調査した Web 上の記事を読んでまとめただけなので、手を動かしての確認はしておらず、理解が甘い部分はご容赦ください 具体的な通信方式やサービス間通信のセキュリティといった具体論までは踏み込めていない。このへんはサービスメッシュやゼロトラストネットワークといったトピックが登場すると思われる これらは次回以降の Todo としています その
::: message info これは[フィヨルドブートキャンプ Advent Calendar 2022 Part.1](https://adventar.org/calendars/7760)の25日目の記事です。 昨日の記事は:@shujiwatanabe:shujiwatanabeさんの[質問しながら出来るようにしていく](https://shu91327.hatenablog.com/entry/2022/12/24/091025)と:@saeyama:saeyamaさんの[Rails/Vue 編集時に画像をD&Dで入れ替えした時のActive Storageの保存方法](https://saeyama.hatenablog.com/entry/2022/12/24/000123)でした。 ::: ↓こういうのを職人が丹精込めて一つ一つ手作りする時代は終わりました。 ```sh
2. 徳丸浩の自己紹介 • 経歴 – 1985年 京セラ株式会社入社 – 1995年 京セラコミュニケーションシステム株式会社(KCCS)に出向・転籍 – 2008年 KCCS退職、HASHコンサルティング株式会社(現社名:EGセキュアソリューションズ株式会社)設立 • 経験したこと – 京セラ入社当時はCAD、計算幾何学、数値シミュレーションなどを担当 – その後、企業向けパッケージソフトの企画・開発・事業化を担当 – 1999年から、携帯電話向けインフラ、プラットフォームの企画・開発を担当 Webアプリケーションのセキュリティ問題に直面、研究、社内展開、寄稿などを開始 – 2004年にKCCS社内ベンチャーとしてWebアプリケーションセキュリティ事業を立ち上げ • 現在 – EGセキュアソリューションズ株式会社取締役CTO https://www.eg-secure.co.jp/ –
※月単価80万円を基準に、7ヶ月分の工数として560万円相当と換算しています。 最初に こんにちは! 普段はIT企業でWebエンジニアとして働いています。 現在はフリーランスとして活動し、Ruby(Ruby on Rails)、TypeScript(Next.js, React)、Pythonなどを使って、フロントエンドとバックエンドの両方に携わっています。 将来はソフトウェアエンジニアとしてアーキテクチャ・設計について自ら意思決定した上、プロジェクトを推進する事が出来るようになりたいです。 そのためさらにスキルを磨いていきたいと思っており、日々技術に対して情熱を持って仕事に取り組んでいます。 以前Qiitaで 退職して560万円相当の工数をかけてお金を稼ぐサービスを開発した という事でBizRankというビジネス書籍を紹介するサービスを開発しました。 今回はその後としてのお話になります。
はじめに 自分は2021年に新卒でWeb系の開発会社にフロントエンジニアとして入社し2022年で2年目になります。 実務ではReact×TypeScriptを利用したフロント周りとNode.js(Nest)やRailsを用いたバックエンド(API)の開発をしています。 その中で使っていたAPI設計について改めて学び直したのでまとめて行きます。 この記事の対象者 エンジニア初心者から中級者 APIについて学びを深めたい人 この記事の目標 APIについて学ぶ 我流ではなく正しいAPI設計について学ぶ この記事でやらないこと 具体的にコードを用いたAPI設計の書き方の説明に関しては下記の記事で解説をしています。 APIについて APIとは APIは"Application Programming Interface"の略で、直訳すると「アプリケーションを使プログラミングを使ってつなぐ」という意味
SECCON Beginners Live 2023「JWTセキュリティ入門」の発表資料です。
こんにちは。 マネーフォワードの新卒Railsエンジニア、きなこ と申します。 マネーフォワードX という組織で、日々プロダクトの開発に勤しんでおります😊 突然ですが皆さんは JWT という技術をご存知でしょうか? 私は趣味でCTFというセキュリティコンテストに出場するのですが、最近ホットだと感じるのがJWTに関連する攻撃です。 今年の1月に初めてJWTを題材にした問題に遭遇し、その後JWTの出題頻度が強まっていると感じ、社内に向けてJWTにまつわる攻撃を通して学ぶための記事を書いたところ、たくさんの反応をいただきました。 今回の記事はその内容を社外向けにアレンジし、ハンズオンを通して実際にJWTを改竄し、受け取るAPIを攻撃することでJWT自体を学べるようにしたものです。 本記事はJWTに興味があるWeb開発者を想定していますが、そうでない方も楽しんでいただけるようにハンズオンを用意し
以下のツイートを読んで気持ちが昂ったので。 みんな、もうSNSでいがみ合うのはやめよう。 平和に好きなJWTの話でもしようよ。 JWTの格納場所はlocalStorageとCookieのどっちが好き?— 徳丸 浩 (@ockeghem) 2022年2月11日 というのも、JWTをセッションに使うときに保存先含めて一時期悩んでいたので、その時の自分の解。 ただ、考えるたびに変化しているので、変わるのかもしれない。 要約 タイトル。 あとは優秀な方々が既に色々考えておられるのでそちらを読むとよいでしょう。 SPAセキュリティ入門~PHP Conference Japan 2021 JWT カテゴリーの記事一覧 - r-weblife どうしてリスクアセスメントせずに JWT をセッションに使っちゃうわけ? - co3k.org JWT形式を採用したChatWorkのアクセストークンについて -
こんにちは、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 、バグバウンティなどを興味分
GitHub Actions入門 ── ワークフローの基本的な構造からOIDCによる外部サービス認証まで GitHubが公式に提供するGitHub Actionsは、後発ながらよく使われるワークフローエンジンとなっています。本記事では、藤吾郎(gfx)さんが、典型的なCI/CDのユースケースに即したワークフローの設定と管理について解説するとともに、注目されているGitHub OIDC(OpenID Connect)の利用についても紹介します。 GitHub Actionsは、GitHubが提供するCI/CDのためのワークフローエンジンです。ワークフローエンジンは、ビルド、テスト、デプロイといったCI/CD関連のワークフローを実行し、定期実行するワークフローを管理するなど、開発におけるソフトウェア実行の自動化を担います。 ▶ GitHub Actions - アイデアからリリースまでのワーク
即戦力人材と企業をつなぐ転職サイト「ビズリーチ」は2009年にサービスを開始し、スカウト可能会員数は190万人以上(2023年1月末時点)のユーザーにご利用いただくサービスに成長しました。 今回、その「ビズリーチ」の認証基盤としてIDaaS(Identity as a Service)のOkta Customer Identity Cloud(Powered by Auth0)(以下Auth0という)の導入を行いました。 本記事では認証基盤を刷新するに至った背景とAuth0を用いて100万を超えるユーザーをログアウトさせることなく移行した方法についてご紹介いたします。 前提 本記事で得られる情報 本記事を読むことで以下のような情報を得ることができます。 IDaaSを選ぶ理由 IDaaSを用いて認証・認可を運用中のプロダクトに組み込んだ事例 運用中のプロダクトに組み込む際に発生しうる課題と対
このビデオについて このビデオは、2021 年 10 月 6 日に開催された 「挫折しない OAuth / OpenID Connect 入門」の理解を深める会 のプレゼンテーション録画です。 2021 年 9 月 18 日発売の「Software Design 2021 年 10 月号」では、OAuth/OIDC が特集され、「挫折しない OAuth/OpenID Connect 入門・API を守る認証・認可フローのしくみ」と題し、Authlete 代表の川崎貴彦が寄稿しました。 本プレゼンテーションでは記事のポイントや、理解を深めるために重要なポイントについて、著者の川崎がお話しします。 文字起こし はじめに 目次 記事の第1章、第2章、第3章は、こういう目次になっています。 ここからピックアップして、 こんなことを話してます、というところを、 紹介したいと思います。 自己紹介 Au
おはようございます、ritouです。 この話に乗っかっていきます。 3行で ログアウト時にJWTを無効化できない実装は今後脆弱性診断で「OWASP Top 10 2021違反」と指摘されるようになりそう(今も個別にされてるかもしれないけど) JWTは単純なフォーマットなので、ステートレスなセッション管理においてログアウトしたときに文字列自体を無効化できない件は独自エンコード方式(一般的にフレームワークのCookieストアと呼ばれているもの)でも起こり得る 「セッションID vs JWTで内包」 以外にも 「セッションIDをJWTに内包」もあり得る。既存の機能を残しつつ「JWTで武装」する選択肢も考えてみてはどうか。 ステートレスなセッション管理でログアウトの際に文字列自体を無効化できない問題 これは前から言われていますし、駆け出し何とか勢のQiita記事に書かれるぐらいには一般的です。 2
複数のクラウドサービスを利用している(マルチクラウド)など、単純には閉域網を構築できない環境でマイクロサービスアーキテクチャを採用する場合には、サービス間の認証認可が必要となる。この場合のサービス間の認証認可方式を決める参考となる、OSSやSaaS、Webサービスで採用方式ついて整理した。 Istio サービスメッシュの実装として有名なIstioではサービス間通信を以下のように制御できる。 Istioの認証認可では認証主体がService Identityというモデルで抽象化され、KubernatesやIstioで定義するService Accountに加えて、GCP/AWSのIAMアカウントやオンプレミスの既存IDなどをService Identityとして扱うことができる。 サービス間の認証 (Peer Authentication) は、各サービス (Pod) に設置するSideca
この記事はRetty Advent Calendar 2019 21日目の記事です。エンジニアの 神@pikatenor がお送りします。11日目の記事に書かれた「弊社エンジニアの神(注・人名であり実名です)」とは私のことです。 qiita.com さて世はまさにマイクロサービス大航海時代、大規模化した組織・肥大化したコードベースのメンテナンスを継続的に行っていくべく、アプリケーションを機能別に分割する同手法が注目を集めていることは皆さんもご存知でしょう。 マイクロサービスアーキテクチャ特有の設計課題はいくつかありますが、今回は認証情報のような、サービス間でグローバルに共有されるセッション情報の管理のパターンについて調べたことをまとめてみたいと思います。 背景 HTTP は本質的にステートレスなプロトコルですが、実際の Web サービス上では複数リクエストをまたがって状態を保持するために、
はじめに Wikipedia の JWT (JSON Web Token) に関する記事が誤っていたので、2020 年 5 月 9 日、英語版、日本語版ともに修正を行いました。 修正前の記事では、JWT のことを「JSON をベースとしたアクセストークンのためのオープン標準である」と説明していました。しかし JWT は用途を限定しない汎用的なデータフォーマットです。アクセストークンのフォーマットとして JWT を採用することは、JWT の応用事例の一つに過ぎません。なお、アクセストークンのフォーマットは必ずしも JWT とは限りません。→ 参考:『図解 JWS/JWE/JWT/IDトークン/アクセストークンの包含関係』 JWT を知らない状態で OAuth と OpenID Connect の学習を始めると、「JWT はアクセストークンのための技術である」、「JWT はユーザ認証のための技
SPAやモバイルアプリから利用するAPIを開発する際の、トークン認証のお話です。 どの認証ライブラリを使うべきという話ではなく、トークン認証の論理的な設計について考察します。 私自身も結論が出ていないので、色んな意見が聞けると嬉しいです。 出発点 ユーザテーブルにアクセストークンを持つのが最も安直な発想だと思います。 ログイン成功時にアクセストークンを発行し、該当ユーザレコードにセット。 同時に有効期限もセットします。 認証時には、アクセストークンが存在し有効期限内であれば、認証を通過させ、 そうでなければ認証失敗とします。 ログアウト時には、該当ユーザレコードのアクセストークンを空にします。 発行日時を持ち、システム内に定義された有効期間をもとに、認証時に計算する方法もあると思います。 Laravel Sanctum 等はそういう実装です(しかもデフォルトでは有効期限なし)。 有効かどう
これは、豆蔵デベロッパーサイトアドベントカレンダー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について 記事は上記のような内容
JWTって何? JWTはJSON Web Tokenの略です。 まずは完成されたJWTを見てみましょう。 eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c この文字列がJWTです。 JWTの特徴を見てみる よく見ると、この文字列は 「.」(ドット) で区切られています。 JWTは次の3つのパーツから構成されています。 ヘッダ(Header) ペイロード(Payload) 署名(Signature) ただの文字列じゃない? JWTは単なる文字列ではありません。 実は、この「ヘッダ」や「ペイロード」をデコードすると、JSON形式のデータ
// auth.ts import NextAuth from "next-auth" import GitHub from "next-auth/providers/github" export const { auth, handlers } = NextAuth({ providers: [GitHub] }) // middleware.ts export { auth as middleware } from "@/auth" // app/api/auth/[...nextauth]/route.ts import { handlers } from "@/auth" export const { GET, POST } = handlers // src/auth.ts import { SvelteKitAuth } from "@auth/sveltekit" impor
私が愛用するオンライン開発ツール インターネット上には、フロントエンド開発者の生活を楽にしてくれる素晴らしいツールが沢山あります。この記事では、私が開発の仕事で頻繁に使っている11のツールについて簡単に説明します。 1. CanIUse Web APIが特定のブラウザで互換性があるのか、モバイルブラウザで使用できるのか、分からないことはありませんか?このオンラインツールを使えば、ブラウザの互換性についてWeb APIを簡単にテストできます。 Can I use―HTML5、CSS3などの対応表。 「Can I use」は、デスクトップとモバイルにおけるフロントエンドWebテクノロジーを支援する、最新のブラウザ対応表を提供します。 caniuse.com Web Share APIのnavigator.share(...)に対応しているブラウザとバージョンを知りたいとします。 結果を見てくだ
カラーミーショップ サービス基盤チームのkymmtです。この記事では、サーバサイドレンダリングするシングルページアプリケーションとAPIサーバからなるWebアプリケーションのセッション管理方法について紹介します。 アプリケーションの構成 構成の概要 今回は例としてEC事業部で提供するカラーミーリピートをとりあげます。構成としては、Railsで作られたAPIサーバ1と、Vue.jsで作られたシングルページアプリケーション(SPA)からなります。また、SPAはExpressが動くフロントエンドサーバでサーバサイドレンダリング(SSR)します。APIサーバはSPAかフロントエンドサーバだけが呼び出します。各ロールはサブドメインが異なります。 APIサーバでセッションIDを持つCookieを発行し、Redisを用いてセッション管理します。また、APIサーバへのセッションが有効なリクエストはフロント
きっかけ 昨年(2021年9月ごろ)に徳丸さんのこのツイートを見て、「2022年にはJWTを用いたセッション管理に代表される、ステートレスなセッション管理は世の中に受け入れられなくなっていくのだろうか?」と思っていました。 OWASP Top 10 2021 A1に「JWT tokens should be invalidated on the server after logout.」(私訳:JWTトークンはログアウト後にサーバー上で無効化すべきです)と書いてあるけど、どうやって無効化するんだ? ブラックリストに入れる?https://t.co/bcdldF82Bw— 徳丸 浩 (@ockeghem) 2021年9月10日 JWT大好きな皆さん、ここはウォッチしないとだめですよ。これがそのまま通ったら、ログアウト機能でJWTの即時無効化をしていないサイトは脆弱性診断で「OWASP Top
はじめに この記事を読んでいるあなたはJWTについて知っているだろうか?JWTは、認証されたユーザを識別するために最も一般的に使用される。JWTは認証サーバから発行されて、クライアント・サーバで消費される。 今回の記事では、Webアプリケーションの認証方法として最も利用されているJWT認証を簡潔に解説する。 本記事の読者の対象 JWT認証について知らない人 JWTのメリット・デメリット、仕組みについて詳しく知りたい人 アプリケーションの認証方法について詳しく知りたい人 JWTとは JSON Web Token(JWT)とは、クライアント・サーバの間で情報を共有するために使われる規格の1つである。JWTには、共有が必要な情報を持つJSONオブジェクトが含まれている。さらに、各JWTはJSONのcontentsがクライアントあるいは悪意のあるパーティによって改ざんされないように、暗号(ハッシュ
はじめに 2023年4月に基盤エンジニアとして Ubie に入社しました nerocrux です。主に Ubie の ID 基盤の開発と保守運用を担当しています。 この記事は、2023 Ubie Engineers アドベントカレンダー 5 日目の記事となります。 Ubie では、モジュラモノリスを採用しつつ、マイクロサービスアーキテクチャも採用しており、領域によってサービスを分けて、それぞれの担当チームが開発と保守運用をしています。 クライアントから一つのリクエストを受け取ったあとに、Ubie のバックエンドではリクエストを受け取ったサービスだけがそのリクエストを処理することもあれば、別のサービスにディスパッチし、複数のサービスがひとつのリクエストを処理して結果を返すこともあります。 マイクロサービス間の通信が Ubie の内部で発生したとしても、必ずしも無制限で自由に行われていいわけで
2019年1月30日 PST 本脆弱性の悪用シナリオの前提条件に関するコミュニティからのフィードバックを受け、私たちはAuth0と協力してCVE-2022-23529を撤回することを決定しました。 本稿で解説したセキュリティの問題はJsonWebTokenライブラリが安全でない方法で使用された場合には依然として懸念されるものです。そのシナリオでは、すべての前提条件を満たせばこの問題を悪用できる可能性があります。私たちは、その場合のリスクの大元はライブラリ側でなく呼び出し側のコードにあることに同意します。 この問題に対処するためJsonWebTokenのコードには重要なセキュリティチェックが追加されました。 jsonwebtoken 8.5.1以前のバージョンをお使いの場合は最新版の9.0.0にアップデートすることをお勧めします。最新版では同セキュリティ問題を含む問題を修正済みで、より安全な
おはようございます。ritou です。 5月下旬ぐらいにチーム内勉強会としてJSON Web Token(JWT)についてわいわいやりました。 その際に作成した資料に簡単な説明を添えつつ紹介します。 このブログではJWTについて色々と記事を書いてきましたが、その範囲を超えるものではありません。 ちょっとだけ長いですが、ちょっとだけです。お付き合いください。それでは始めましょう。 JSON Web Token boot camp 2020 今回の勉強会では、JWTについて概要、仕様紹介という基本的なところから、業務で使っていくにあたって気をつけるべき点といったあたりまでカバーできると良いなと思っています。 JSON Web Token 概要 まずは概要から紹介していきます。 JSON Web Tokenの定義とはということで、RFC7519のAbstractの文章を引用します。 JSON W
こんにちは、BOXILの開発をしている徳田(@haze_it_ac) です。 今回は業務と少し離れた話をしてみます。 はじめに みなさんは仕事以外でもWebアプリケーションを作っていますか? 作りまくっている人も、仕事以外ではコードを書かない人も居るかと思います。 私は気になったライブラリを見つけたり、こういう実装ってできないかな?と思った際に、簡単なWebアプリケーションを作って試しています。 この記事ではその中で、ゴールデンウィーク中に "簡単に作れて、運用が楽な SPA/SSR + API Server 構成の小さなWebサービス" を考えて試した際の構成と、作成手順を紹介します。 サンプル 画面 https://blog-sample-fe.now.sh/ 見た目が雑で申し訳ないのですが、サンプルとして 会員登録 ログイン 会員ページ ログアウト 機能を実装したものです。 構成 全
今個人で作ってるアプリの 認証 + Graphql の部分を抜き出して GitHub に公開した。 mizchi/next-boilerplate-20200727 next.js + vercel + firebase は (パーツを良く選べば) 最高 next.js はルーティングを持つページを作るには最高で、サーバー、静的サイト、JAM スタック、AMP と必要に応じて選択できる。React ベースならこれ一択。 認証サーバーの実装は毎度疲れるし、Firebase Athunetication はこの点においては OAuth Secret を置くだけ + Custom Provider も作れるので、最高。 それと比べて firestore は、ちょっと前に firestore べったりでアプリを試作したことがあったのだが、型がないためにかなり扱いづらく、また読み書きの速度が遅くパフ
この記事は弁護士ドットコム Advent Calendar 2024 の 21 日目の記事です。 はじめに リーガルブレイン開発室の tsuchiya です。 先日、セッション ID を JWT に内包するという記事を読みました。 "JWT=ステートレス"から一歩踏み出すための考え方 上記記事では、 セッション ID を内包した JWT を活用する ことについて紹介しています。 JWT の性質を最大限活用したもので、非常に共感できる内容でした。 本記事では上記記事をうけて、セッション ID を内包した JWT をセッション Cookie として使用する処理を PHP で実装してみたので、その内容について紹介します。 JWT とは 本記事では、JWT の詳細な仕様に関する説明は省略しますが、本記事を理解するうえで重要になる性質について簡単に紹介します。 JSON Web Token(JWT)
スライド概要 シングルページアプリケーション(SPA)において、セッションIDやトークンの格納場所はCookieあるいはlocalStorageのいずれが良いのかなど、セキュリティ上の課題がネット上で議論されていますが、残念ながら間違った前提に基づくものが多いようです。このトークでは、SPAのセキュリティを構成する基礎技術を説明した後、著名なフレームワークな状況とエンジニアの技術理解の現状を踏まえ、SPAセキュリティの現実的な方法について説明します。 動画はこちら https://www.youtube.com/watch?v=pc57hw6haXk
# 簡単のため一部ファイルは割愛しています go-graphql-jwt-api/ ├── build/ │ ├── db/ │ └── docker/ │ ├── cmd/ │ └── main.go │ ├── pkg/ │ ├── adapter/ │ │ └── http/ │ │ ├── handler/ │ │ │ ├── graph_handler.go │ │ │ └── login_handler.go │ │ │ │ │ ├── middleware/ │ │ │ └── auht_middleware.go │ │ │ │ │ ├── resolver/ │ │ │ ├── mutation.resolvers.go │ │ │ └── query.resolvers.go │ │ │ │ │ └── route/ │ │ └── ro
2020年3月17日、株式会社Authleteが主催する「OAuth & OIDC 勉強会 リターンズ【入門編】」が開催。同社の共同創業者であり、プログラマー兼代表取締役でもある川崎貴彦氏が、OAuth 2.0 / OIDCの仕様について解説しました。 冒頭は、OAuth 2.0の概念や認可・認証までの流れと、それを理解する上で避けては通れない3つの技術仕様(JWS・JWE・JWT)についての解説です。 OAuth 2.0とは 川崎貴彦氏:株式会社Authleteの川崎です。本日は「OAuthとOpenID Connectの入門編」ということでオンライン勉強会を開催しますので、よろしくお願いします。最初にOAuth 2.0の概要の説明からです。 ブログに書いてある内容と一緒なんですが、まずユーザーのデータがあります。このユーザーのデータを管理するのが、リソースサーバーです。このユーザーのデ
おはようございます、ritouです。 (⚠️認可イベントの識別子のあたり、ちょっと見直しました!最初に見ていただいた方はもう一回どうぞ!) 前回、ハイブリッド型と呼ばれる OAuth 2.0 のトークン実装について書きました。 ritou.hatenablog.com その続きとして JWT(JWS) + RDBでできる実装例を紹介します。 理解するにはそれなりの OAuth 2.0 に関する知識が必要になるかもしれませんが、よかったら参考にしてみてください。 何を考えたのか OAuth 2.0のRefresh Token, Access Tokenを考えます。 要件から整理しましょう。 要件 結構ありますが、最低限の OAuth 2.0 の Authorization Server を実装しようと思ったらこれぐらいはやらないといけないでしょう。 RFC6750 で定義されている Bear
ある日,HTML5のLocal Storageを使ってはいけない がバズっていた. この記事でテーマになっていることの1つに「Local StorageにJWTを保存してはいけない」というものがある. しかし,いろいろ考えた結果「そうでもないんじゃないか」という仮定に至ったのでここに残しておく. 先の記事では,「Local StorageにJWTを保存してはいけない」の根拠として「XSSが発生した時,攻撃者がLocal Storageに保存したJWTを盗むことが出来てしまう」といったセキュリティ上の懸念事項が挙げられていた. これに対し,クッキーを用いたセッションベースの認証では,セッションIDをクッキーに保存する.クッキーにHttpOnlyフラグをつけておけば,JavaScriptからはアクセスできず,XSSが発生しても攻撃者はセッションIDを読み取ることが出来ない. 一見すると,これは
JWS/JWE/JWT/IDトークンの包含関係 JWS (JSON Web Signature) と JWE (JSON Web Encryption) の直列化方法には、それぞれ JSON 形式とコンパクト形式がある。 JWT (JSON Web Token) は JWS か JWE だが、いずれにしてもコンパクト形式である。仕様でそう決まっている。 仕様により、ID トークンには署名が必要なので、ID トークンは JWS もしくは「JWS を含む JWE」という形式をとる。 ID トークンは「JWE を含む JWS」という形式はとらない。なぜなら、仕様により、ID トークンを暗号化する際は「署名してから暗号化」という順番と決まっているため。 アクセストークン/JWT/IDトークンの包含関係 アクセストークンの実装が JWT だとは限らない。 仕様により、ID トークンは必ず JWT で
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く