OAuth 2.0 / OIDC を理解する上で重要な3つの技術仕様
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の概要の説明からです。 ブログに書いてある内容と一緒なんですが、まずユーザーのデータがあります。このユーザーのデータを管理するのが、リソースサーバーです。このユーザーのデ
OAuth アクセストークンの実装に関する考察 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに この記事では、OAuth 2.0 のアクセストークンの実装に関する考察を行います。本記事の執筆者本人による動画解説も『OAuth & OIDC 勉強会 【アクセストークン編】』で公開しておりますので、併せてご参照ください。 English version of this article is here → "OAuth Access Token Implementation". 1. アクセストークン実装方法の分類 OAuth のアクセストークン※１の実装方法は認可サーバーの実装依存です。 実装依存ではありますが、RFC 67
JWT+RDBを用いたOAuth 2.0 ハイブリッド型トークンの実装例 - r-weblife
おはようございます、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
SPAのログイン認証のベストプラクティスがわからなかったのでわりと網羅的に研究してみた〜JWT or Session どっち？〜 - Qiita
SPAのログイン認証のベストプラクティスがわからなかったのでわりと網羅的に研究してみた〜JWT or Session どっち？〜JavaScriptRailsJWT認証React SPAのログイン周りについて、「これがベストプラクティスだ！」という情報があまり見当たらないので、様々な可能性を模索してみました。 いろいろな状況が想定され、今回記載する内容に考慮の漏れや不備などがありましたら是非コメントでご指摘いただきたいです！特に「おすすめ度：○」と記載しているものに対しての批判をどしどしお待ちしております！ この記事でおすすめしているものであっても、ご自身の責任で十分な検討・検証の上で選択されてください。 前提 想定しているAPIは、 ログイン外のAPIにはPOST/PUT/DELETEのものがなく、GETのみ GETのAPIにはDBを更新するなどの操作がない とし、そのためログイン外では
RFC 8725 JSON Web Token Best Current Practices をざっくり解説する - Qiita
ritou です。 今回は RFC 8725 JSON Web Token Best Current Practices を紹介します。 みんな大好き JWT (JSON Web Token) の BCP ときたらチェックせずにはいられないでしょう。 概要 JWTは 署名/暗号化が可能な一連のクレームを含む、URLセーフなJSONベースのセキュリティトークン です JWTは、デジタルアイデンティティの分野および他のアプリケーション分野の両方の多数のプロトコルおよびアプリケーションにて、シンプルなセキュリティトークンフォーマットとして広く使用/展開されています このBCPの目的は、JWTの確実な導入と展開につながる実行可能なガイダンスを提供することです ということで、何かのフレームワークでもプロトコルでもなければJWTを使ったユースケース考えたよって話でもなく、JWTを導入する上で基本的な部
Webアプリケーションのセッション管理にJWT導入を検討する際の考え方 - r-weblife
おはようございます、ritou です。 qiita.com これの初日です。 なんの話か 皆さんは今まで、こんな記事を目にしたことがありませんか？ Cookie vs JWT 認証に JWT を利用するのってどうなの？ JWT をセッション管理に使うべきではない！ リンク貼るのは省略しますが、年に何度か見かける記事です。 個人的にこの話題の原点は最近 IDaaS(Identity as a Service) として注目を集めている Auth0 が Cookie vs Token とか言う比較記事を書いたことだと思っていますが、今探したところ記事は削除されたのか最近の記事にリダイレクトされてるようなのでもうよくわからん。 なのでそれはおいといて、この話題を扱う記事は クライアントでのセッション管理 : HTTP Cookie vs WebStorage(LocalStorage / Sess
OAuth 2.0 の勉強のために認可サーバーを自作する - Qiita
逆に、RFC 6749 以外で定義されている認可フローをサポートする場合、新たに別のエンドポイントの実装が必要になることがあります。例えば CIBA（Client Initiated Backchannel Authentication）ではバックチャネル認証エンドポイント（backchannel authentication endpoint）、デバイスフロー（RFC 8628）ではデバイス認可エンドポイント（device authorization endpoint）の実装が求められます。 この記事では、認可エンドポイントとトークンエンドポイントを実装します。サポートする認可フローは認可コードフローのみ、サポートするクライアント・タイプはパブリックのみとします。 2. 注意点 下記の理由、および書かれていないその他の理由により、本実装は商用利用には適していません。 セキュリティー上必須
（その1）「不正指令電磁的記録に関する罪」について、最高裁判所へ情報公開請求をしました - ろば電子が詰まつてゐる
兵庫県警が「不正指令電磁的記録に関する罪（刑法１６８条の２および３）」について起こした無限アラート事件について、前回の続きです。 今回は、兵庫県警ではなく最高裁判所へ情報公開請求をしました。そのためナンバリングを（その1）と振り直しました。二つは並列して進めていきます。これまでの動きを追いたい方は、Twitterのmomentにまとめてあるのでこちらで追ってください。 https://twitter.com/i/moments/1145015327027154944 今回の概要 - 最高裁判所への情報公開請求 前回の記事、（その6）兵庫県警へ「不正指令電磁的記録に関する罪」の情報公開請求をしましたでも書きましたが、今回の無限アラート事件のひとつの要因は法務省が曖昧すぎる法律の条文を放置しているという点もあります。 現在の「不正指令電磁的記録に関する罪」は、この曖昧な条文を「運用でカバー」し
（その6）兵庫県警へ「不正指令電磁的記録に関する罪」の情報公開請求をしました - ろば電子が詰まつてゐる
しばらく間が開いてしまいました。本業の方が忙しかったり色々あって2ヶ月ぶりですが、マイペースで続けます。兵庫県警へ情報公開請求をしていた公文書が届きましたので、今回はそちらを見ていきたいと思います。 が、その前にいったんあらすじをつけておきましょう。 これまでのあらすじ 「JavaScriptのforループでalertウィンドウを出すだけ」という、いわゆるジョークプログラムへのリンクを張った3人が、兵庫県警によって1名(未成年)が補導、2人が書類送検される予定という事案が発生しました。 本件に対し、兵庫県警の捜査が極めてずさんかつ法律の解釈が曖昧すぎることから、「どのような内容をもって犯罪行為とするかの構成要件等を記載した文書」を兵庫県警へ情報公開請求しました。 請求されるのを待っている間に他にも調べていたところ、警察庁が47都道府県警に対して通達「丁情対発第108号・丁情解発第27号」を
（その5）兵庫県警へ「不正指令電磁的記録に関する罪」の情報公開請求をしました - ろば電子が詰まつてゐる
（その4）兵庫県警へ「不正指令電磁的記録に関する罪」の情報公開請求をしました 兵庫県警へ「不正指令電磁的記録に関する罪」の情報公開請求をしました（その3） 兵庫県警へ「不正指令電磁的記録に関する罪」の情報公開請求をしました（その2） 兵庫県警へ「不正指令電磁的記録に関する罪」の情報公開請求をしました（その1） 目次 はじめに：前提知識 「無限アラート事件」という呼び名は正しいのか（集合論） 進捗報告 よくある質問 CoinHive事件は（控訴されたけど）無罪が出たから、少しは安心できる？ 前回の記事で、都道府県警の上は警察庁って書いてたけど、運営上は各都道府県だよ? 警察庁の責任 検挙数とノルマ 警察庁通達 丁情対発第108号・丁情解発第27号 その他の通達 兵庫県警の責任について 私への連絡先 【PR】淡路島観光 はじめに：前提知識 CoinHive事件に皆さん夢中になっているので、誤解
（その4）兵庫県警へ「不正指令電磁的記録に関する罪」の情報公開請求をしました - ろば電子が詰まつてゐる
breaking news 最初に、ニュースを入れておきます。 既にご存じの方も多いでしょうが、CoinHive事件について、一審で無罪判決だったモロさんに対して横浜地検が判決に不服として控訴しました（コインハイブ事件で検察側が控訴 無罪判決に不服）。これにより高等裁判所で裁判が続くこととなりました。非常に、非常に残念です。 今後の裁判に影響があると多大な迷惑をかけると思いますので、具体的な問題点の指摘等は私からは控えます。ただ、やはり、本当に残念です。 これで日本のIT分野における国際競争力は、確実に遅れることでしょう。既に取り返しの付かないレベルに達しつつあります。 これまでのあらすじ 友人から、最近、以下のような意見を頂きました。 最近のお前の記事は、似たようなタイトルでよく分からん。まず、「そのｎ」は記事先頭に書かないと後ろが切れてキレる、前に書け。それから毎回、あらすじリンク集を
兵庫県警へ「不正指令電磁的記録に関する罪」の情報公開請求をしました（その3） - ろば電子が詰まつてゐる
先日、2019年3月11日、以下の「不正指令電磁的記録に関する罪」に関する公文書公開請求を行いました前回の記事参照。 ここで請求した文書は、「兵庫県警において刑法第百六十八条の二又は第百六十八条の三（不正指令電磁的記録に関する罪）に基づく取締りその他の運用を行うにあたり、どのような内容をもって犯罪行為とするかの構成要件等を記載した文書（具体例を含む）」です。 これに対し、2019年3月27日に回答が郵送で届きましたので報告します。回答は以下の通り「4月10日までの期間延長」でした。 これは公開を延長するという意味ではなく、「公開するか非公開とするかの判断を含めて延長する」ということに注意してください。 また延長理由は、「請求内容が複雑であり、公文書の特定が困難であるため、15日以内に公開決定等をすることが困難である。」でした。 考察 期間延長が来ることは予想していたので、そこは特になんとも
兵庫県警へ「不正指令電磁的記録に関する罪」の情報公開請求をしました（その1） - ろば電子が詰まつてゐる
（追記）これまでの活動を時系列にまとめたTwitterのモーメントを作りました。記事はこちらで追えますので、合わせてご覧ください。 Twitter Moment: 兵庫県警へ「不正指令電磁的記録に関する罪」の情報公開請求をしました はじめに 先日、「forループでalertウィンドウを出すだけ」という、いわゆるジョークプログラムへのリンクを張った3人が、兵庫県警によって1名(未成年)が補導、2人が書類送検される予定という事案が発生しました。(for文無限ループURL投稿で補導された件についてまとめてみた) この事案について、兵庫県警に対し兵庫県情報公開条例に基づいて以下の情報公開請求を行いましたので記録します。 なお本記事については、以前に同様に神奈川県警に対して情報公開請求を行った 梅酒みりん 様へお願いし、文面について利用させて頂くことを快諾頂きました。この場を借りて感謝を申し上げます
JWT形式を採用したChatWorkのアクセストークンについて - ChatWork Creator's Note
JWTを使うことは難しい？ こんにちは、かとじゅん(@j5ik2o)です。最近、JWTに関する以下のブログが話題です*1。 どうしてリスクアセスメントせずに JWT をセッションに使っちゃうわけ？ - co3k.org このブログで言及されているのは、JWTをセッションの保存先に選ぶことで「何が問題なの？」に書かれているリスクがあるよ、という話*2。確かにいくつか検討することがありますね。 auth0.hatenablog.com auth0の中の人？よくわからないけど、反論的なブログエントリが公開されています。この記事では、指摘の問題が起こらないように設計するのはあたり前では？という意見みたいです。まぁごもっともではないでしょうか。 私も技術そのものというより、要件に合わせて技術を組み合わせる設計の問題だと思っています。加えて、JWTを利用することはそんなに難しいことかという疑問があった
仮想通貨マイニング（Coinhive）で家宅捜索を受けた話 - Webを楽しもう「ドークツ」
表題の通り、お恥ずかしい限りではありますが、人生ではじめて警察（神奈川県警！）のお世話になる運びとなりました。 罪状としては「不正指令電磁的記録 取得・保管罪」、通称ウイルス罪とのことで、まさに青天の霹靂の思いです。 以下ではこの度起こったことを可能な範囲でありのまま共有できればと思います。 この記事の目的まず、この記事を公開した目的は「他のクリエイターの人に同じ経験をして欲しくない」という一点に尽きます。 手前味噌ではありますが、私はこれまで多くの尊敬するクリエイターの方々と同じように「良いクリエイターであろう」と腐心し、できうるかぎりの努力をしてきたつもりです。 今回の件に関しても決して私利私欲のためではなく、あくまでユーザーのためにできることを、と模索した結果でした。 それがこのような形で取り沙汰されることとなり、残念という他ありません。 忸怩たる思いではありますが、この件から何かし
Web サービスにおける SSL の選定 - ボクココ
ども、@kimihom です。 先日、自社のサービスを EV SSL へ適用したので、それに至った経緯と SSL について思っていることを記す。 SSL 化の流れ もはや、今時のサービスで SSL(HTTPS) 化していないWebサービスはほとんどなくなった。ましてや企業毎に重要な情報を保存するケースの多い SaaS などでは HTTPS 化は必ずしなくてはならない対応の一つとなっている。個人のページや 会社HP など、 HTTP でも特に指摘されることがなかったようなサイトでも、SSL を利用することが重要になってきている。SSL を適用していないページの検索順位が下がってしまたり、ページ閲覧時に Chrome から警告表示されてしまうためである。 その流れの中で、もはや私たちが HTTPS を使わない理由が存在しない。今では、 Let's Encrypt のような無料の SSL も登場
ゲームでよくされるチート手法とその対策 〜アプリケーションハッキング編〜 - Qiita
ゲーム、特にソシャゲ、ネトゲにおいて様々なハッキング(チート)が実際に行われます。 大きく分類すると、アプリケーションハッキング(クライアントサイドでのハッキング)とネットーワークハッキング(サーバーへのハッキング)とその他のハッキングがあります。 多くはエンジニアがよくやらかすバグであったり、知識(経験)不足を狙ってくるものです。 今回は内容のボリュームの関係上、アプリケーションハッキングについてのみ、実際によく行われるチート行為やその方法、対策などについて中心に挙げていきたいと思います。 ボタン連打 何が起こる? コスト(課金石など)を払うことなく無限にアイテムが増殖する。 やり方 上記のような「ボタン」を連打する。 対策 データベースの排他制御(トランザクション + ロック)を行う。 連打ができないように一度ボタンを押したら処理が完了するまで押せないようにする。 具体例・解説 1.に
これが Cloud Native な セキュリティログ分析だ (仮)
Cookpad techconf 2018のLTで講演した資料です
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ITエンジニア向けのトレンド情報 | Forkwell Press （フォークウェルプレス）
ITエンジニア向けのトレンド情報 | Forkwell Press （フォークウェルプレス）