Authorization Code Flow with PKCE Clientの実装（Node.js） - Qiita
はじめに RFC7636 PKCE（Proof Key for Code Exchange by OAuth Public Clients）は認可コード横取り攻撃の対策(authorization code interception attack)として策定された仕様です。 また、PKCEは認可コード横取り攻撃にかかわらず、OAuth2.0におけるCSRFの対策としても機能します。 なお、stateによるCSRF対策ではクライアントが検証を実施するのに対して、PKCEによるCSRF対策では認可サーバーが検証を実施するという違いがあります。（PKCEを利用した場合でも、クライアントが固定値などの脆弱なcode_challenge、code_verifierを利用するとCSRFに対して脆弱になるためクライアントに対策の責務がないわけではありません） PKCEはスマートフォンアプリなどのPubl
30分でOpenID Connect完全に理解したと言えるようになる勉強会
社内向け勉強会で発表した内容です。 30分でと書いてありますが、実際には50分かかりました。 また時間の関係で結構省いたりしている箇所があります。 2020/07/19追記 ご指摘をいただいた箇所を多々修正いたしました。 特にOIDCとSPAの章が初版とは大幅に変更されていますのでご注意く…
ID連携におけるCSRF対策のチェック方法 - r-weblife
こんばんは、OAuth👮♂️です。 緊急事態宣言、外出自粛、みなさまどうお過ごしでしょうか？ お家に高い椅子と4KディスプレイとYouTuber並みのマイクを準備し、ようやくOAuth/OIDCを用いたID連携機能の実装に手をつけられるようになった頃かと思います。 本日はID連携時のCSRF対策について、動くものがある状態からのチェックの方法を紹介します。 手元で開発したサービスの登録とかログインにソーシャルログイン機能をつけて「おっ、IdPと繋がった！」ってなったら、Qiitaにその手順を晒すまえにこういうのを試してみましょう。 IdPに遷移する時のURLを確認する ライブラリとかで作る場合は、登録もログインも既存アカウントへの連携も同じような処理が行われるはずです。 なのでだいたいどこでも良いと思います。 ※画像はイメージです ※画像はイメージです Googleでログイン機能とかを
Authlete の OAuth 2.0 / OIDC 実装ナレッジ 完全に理解した - r-weblife
お疲れ様です。ritouです。 OAuth 2.0 / OIDC 実装の刺激が欲しくなったので(?)、Authlete 社が公開しているナレッジサイトの OIDC / OAuth 2.0 に関する部分を読むことにしました。 kb.authlete.com この記事は、OAuth 2.0 / OIDC を完全に理解した上で Authlete というプロダクトについてなんとなくイメージがついていないとニヤニヤできないかもしれません。 Authlete は "サードパーティーアプリケーションから Web APIへのアクセス制御を行うために必要とされる『認可』の仕組みを提供するクラウドサービス" ですとどこかに書いてありました。 これは個人的な考えですが、RFCなどで定義された仕様を利用するプロダクトというのは、仕様で定義されている機能を設計/実装と、仕様で定義されていない部分や複数の仕様で定義さ
OAuth 2.0/OIDCに入門した開発者が仕様沼に潜るための次のステップとは？ - r-weblife
お疲れ様です、ritou です。 OAuth 2.0やOIDCの入門書(?)を読み終えた開発者の方に、仕様を理解していくための次のステップは何があるかを聞かれました。 そもそもそんなこと言う人は クライアントを実装したい(しなければならない) 認可サーバーを実装したい(しなければならない) セキュリティエンジニアを名乗っていてこの分野を抑えときたい ただ単純に興味がある : そんな人いる？ とかそんな感じな気はしますが、基本的なフローを乗り越えた先に広がる仕様沼への潜り方に戸惑っておられるようでした。 そこで、いわゆる RFC6749/6750/7636 あたりを完全に理解した開発者が山ほどある仕様にどう立ち向かっていくかを考えます。 仕様にも色々ある IETF の OAuth関連の仕様、いっぱいあります。密です。密です。みみみみみみみみ... tools.ietf.org 去年に一回まと
OAuth 2.0 クライアント認証 - Qiita
はじめに この記事では、OAuth 2.0 の『クライアント認証』について説明します。 RFC 6749 に記述されているクライアント認証方式のほか、クライアントアサーションやクライアント証明書を用いるクライアント認証方式についても説明します。 1. クライアント認証方式 1.1. トークンエンドポイント 認可サーバーがあります。 認可サーバーからアクセストークンの発行を受けたいクライアントアプリケーションがあります。 アクセストークンは、幾つかの例外を除き、認可サーバーのトークンエンドポイントから発行されます。そのため、認可サーバーはトークンエンドポイントを用意します。 クライアントアプリケーションは、アクセストークンの発行を受けるために、トークンエンドポイントにトークンリクエストを投げます。 認可サーバーは、トークンレスポンスを返します。この応答の中に、アクセストークンが含まれます。
第4回：Spring Security 5でサポートされたOAuth 2.0 Loginの動作をカスタマイズしてみる - Qiita
今回は、実際のアプリケーション開発を意識して、Spring Seucirtyが提供しているデフォルト動作をカスタマイズする方法をいくつか紹介していきたいと思います。 シリーズ 第1回：Spring Security 5でサポートされるOAuth 2.0 LoginをSpring Bootで使ってみる 第2回：Spring Security 5でサポートされるOAuth 2.0 Loginの処理の流れを(大まかに)理解する 第3回：Spring Security 5でサポートされたOAuth 2.0 Loginの処理の流れを(深く)理解する 動作検証バージョン Spring Boot 2.0.0.M7 Spring Security 5.0.0.RELESAE カスタマイズポイント 本エントリで紹介するカスタマイズポイントは以下の５つです。本エントリで紹介するのは、Spring Securi
第3回：Spring Security 5でサポートされたOAuth 2.0 Loginの処理の流れを(深く)理解する - Qiita
前回「Spring Security 5でサポートされるOAuth 2.0 Loginの大まかな処理の流れを理解する」で大まかな処理の流れを紹介したので、それらをさらにブレークダウンした処理の流れなどをみていきたいと思います。 前提バージョン Spring Boot 2.0.0.M7 Spring Security 5.0.0.RELEASE 認可要求 クライアントAPからプロバイダの認可画面を表示（＝正確にはクライアントからプロバイダへリダイレクト）する時の処理フローをみていきます。前回紹介した図だと、赤線で囲んだところがここでの説明対象になります。 認可要求(認可画面表示要求)が行われると、OAuth2AuthorizationRequestRedirectFilterを起点として、ClientRegistrationRepository、AuthorizationRequestRep
第2回：Spring Security 5でサポートされるOAuth 2.0 Loginの処理の流れを(大まかに)理解する - Qiita
2017-11-23 21:40:39.451 INFO 66053 --- [ost-startStop-1] o.s.b.w.servlet.FilterRegistrationBean : Mapping filter: 'characterEncodingFilter' to: [/*] 2017-11-23 21:40:39.451 INFO 66053 --- [ost-startStop-1] o.s.b.w.servlet.FilterRegistrationBean : Mapping filter: 'hiddenHttpMethodFilter' to: [/*] 2017-11-23 21:40:39.451 INFO 66053 --- [ost-startStop-1] o.s.b.w.servlet.FilterRegistrationBean : Mappi
第1回：Spring Security 5でサポートされるOAuth 2.0 LoginをSpring Bootで使ってみる - Qiita
第1回：Spring Security 5でサポートされるOAuth 2.0 LoginをSpring Bootで使ってみるJavaOAuthspring-securitySpringBoot Spring Security 5の目玉であるOAuth 2.0(& OpenID Connect 1.0)の認可サーバと連携したログイン機能を、Spring Boot上で使う方法を紹介します。（今回はSpring Boot上で使う方法の紹介だけにとどめます→仕組みの話は乞うご期待！！） 動作検証バージョン Spring Boot 2.0.0.M7 Spring Security 5.0.0.RELEASE Tomcat 8.5.23 NOTE: 2017/12/2 : Spring Boot 2.0.0.M7 (Spring Security 5.0.0.RELEASE)ベースに書き換えました。
OAuth徹底入門 セキュアな認可システムを適用するための原則と実践 | 翔泳社
OAuthは近年、WEBアプリケーションで使われる主要な認可プロトコルです。本書ではOAuthをどのようなプラットフォームでも適用できるように解説をしています。 本書は全体で16章あり、4つのパートに分割しています。パート1にあたる第1章と第2章はOAuth 2.0のプロトコルの概要を説明しており、基盤となる知識を得るための読み物としています。パート2は第3章から第6章までとなっており、OAuth 2.0のエコシステム全体をどのように構築するのかについて示しています。パート3は第7章から第10章までとなっており、OAuth 2.0のエコシステムにおけるさまざまな構成要素が持つ脆弱性について説明しており、その脆弱性をどのように回避するのかについて述べています。最後のパートは第11章から第16章までで構成されており、OAuth 2.0を核とした次の世代のプロトコルについて語っており、標準や仕様
Why you should stop using the OAuth implicit grant!
No one should any longer use the implicit grant! That’s what IETF’s OAuth working group, the authority for official OAuth specifications, recommends in the upcoming OAuth 2.0 Security Best Current Practice RFC. The decision was met during the IETF meeting this week in Bangkok. Here is what the working group document says: The implicit grant (response type “token”) and other response types causing
GCP と OAuth2
はじめにGCP のサービスにプログラムからアクセスするためには必ず認証・認可が必要ですが、以下のような様々なコマンドや概念が出てくるので少しとっつきにくい印象があります。 gcloud auth logingcloud auth application-default loginService AccountApplication Default Credentialsこれらの概念は認証・認可のベースとなっている OAuth2 の文脈で眺めてみると全体像が理解しやすくなるので、本記事でまとめてみたいと思います。 GCP での認証・認可GCP の認証・認可は一部(*)を除いて全て OAuth2 ベースでやり取りされています。(* API Key) OAuth2 は三者間の手続きです。 3-Legged OAuth2Client が Resource Owner の代わりに Resource
JWT形式を採用したChatWorkのアクセストークンについて - ChatWork Creator's Note
JWTを使うことは難しい？ こんにちは、かとじゅん(@j5ik2o)です。最近、JWTに関する以下のブログが話題です*1。 どうしてリスクアセスメントせずに JWT をセッションに使っちゃうわけ？ - co3k.org このブログで言及されているのは、JWTをセッションの保存先に選ぶことで「何が問題なの？」に書かれているリスクがあるよ、という話*2。確かにいくつか検討することがありますね。 auth0.hatenablog.com auth0の中の人？よくわからないけど、反論的なブログエントリが公開されています。この記事では、指摘の問題が起こらないように設計するのはあたり前では？という意見みたいです。まぁごもっともではないでしょうか。 私も技術そのものというより、要件に合わせて技術を組み合わせる設計の問題だと思っています。加えて、JWTを利用することはそんなに難しいことかという疑問があった
トークンを利用した認証・認可 API を実装するとき Authorization: Bearer ヘッダを使っていいのか調べた - Qiita
トークンを利用した認証・認可 API を実装するとき Authorization: Bearer ヘッダを使っていいのか調べたAPIOAuthWeb TL;DR HTTP でトークンを利用した認証・認可をする手法として RFC 6750 がある OAuth に限らず、トークンを利用して認証・認可する機構の一部として Authorization: Bearer ヘッダを使うことができる 使い方について詳しくはこの記事の下のほうに書いた 要求 トークンを利用した認証・認可機構を持つ API を作りたい クライアントがトークンを HTTP リクエストに含めて送信し、サーバはトークンを検証してリソースへのアクセスを許可したい Authorization: Bearer トークン ヘッダでトークンを送る API あるよね、ああいうやつ 疑問 Authorization: Bearer ヘッダは OA
図解：OAuth 2.0に潜む「5つの脆弱性」と解決法
SNSなど複数のWebサービスが連携して動くサービスは広く使われている。連携に必要不可欠なのが、アクセス権限をセキュアに受け渡すための「OAuth 2.0」といった仕組みだ。今回はOAuth 2.0に関連する代表的な5つの脆弱（ぜいじゃく）性と攻撃手法、対策についてシーケンス図を使って解説する。 OpenID Foundation Japan Evangelistのritouです。 連載第1回では、RFCが公開されてから5年が経過した「OAuth 2.0」を振り返り、3つのユースケースを通じて、アクセス権限を受け渡す仕組みを紹介しました。OAuth 2.0はさまざまなユースケースに適用できます。その際、開発者はアプリケーションが動作する環境の特性を考慮しながら、仕様で定義されている処理を実装する必要があります。 今回は、脆弱（ぜいじゃく）性を作り込まないOAuth 2.0の実装手法を紹介し
OAuth 2.0 全フローの図解と動画 - Qiita
RFC 6749 (The OAuth 2.0 Authorization Framework) で定義されている 4 つの認可フロー、および、リフレッシュトークンを用いてアクセストークンの再発行を受けるフローの図解及び動画です。動画は YouTube へのリンクとなっています。 English version: Diagrams And Movies Of All The OAuth 2.0 Flows 追記 (2019-07-02) 認可決定エンドポイントからクライアントに認可コードやアクセストークンを渡す方法については、別記事『OAuth 2.0 の認可レスポンスとリダイレクトに関する説明』で解説していますので、ご参照ください。 追記（2020-03-20） この記事の内容を含む、筆者本人による『OAuth & OIDC 入門編』解説動画を公開しました！ 1. 認可コードフロー RF
Google API OAuth2.0のアクセストークン&リフレッシュトークン取得手順メモ - Qiita
はじめに Googleドライブ上のスプレッドシートを読み書きするアプリ作成のため Google APIの手続きを行ったのですが、その手続きがとっても面倒でした。 なので、メモしておいた手順を私的な備忘録としてこちらに公開してみます。 今回リフレッシュトークンがどうしても必要だったのですが、 仕様変更で以前よりリフレッシュトークンの取得が若干面倒になったようです。 以下は、リフレッシュトークン取得を目指したやり方になります。 １、取得に使うGoogleアカウント作成、ログイン ２、Google Developers Consoleにアクセス https://console.developers.google.com (設定でサイトを日本語に変更可能だが、翻訳がややこしいので英語版推奨) ３、API ProjectをCreate、左メニューのAPIs&auth -> APIsから使いたいAPI
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - jack-berkut/spring-security-oauth-demo: Spring Fest 2019 で紹介したデモアプリケーションです。
Javaで実装して学ぶOAuth 2.0！
