OpenID Connectのフローや、JWKやPKCEについて解説
2020年3月17日、株式会社Authleteが主催する「OAuth & OIDC 勉強会 リターンズ【入門編】」が開催。同社の共同創業者であり、プログラマー兼代表取締役でもある川崎貴彦氏が、OAuth 2.0 / OIDCの仕様について解説しました。本記事では、OpenID ConnectのフローやJWKとIDトークンの関係、セキュリティ的に非常に重要かつ必須なPKCEについてわかりやすく解説していきます。 OAuth 2.0フローとOpenID Connectフローとの関係 川崎貴彦氏：今度はOpenID Connectのフローの説明をします。 OAuth 2.0では認可エンドポイントを使うフローとして、認可コードフローとインプリシットフローの2つがあります。認可コードフローの認可リクエストとインプリシットフローの認可リクエストは、どうなっているかというと、まずresponse_typ
「挫折しない OAuth / OpenID Connect 入門」のポイント - Authlete
このビデオについて このビデオは、2021 年 10 月 6 日に開催された 「挫折しない OAuth / OpenID Connect 入門」の理解を深める会 のプレゼンテーション録画です。 2021 年 9 月 18 日発売の「Software Design 2021 年 10 月号」では、OAuth/OIDC が特集され、「挫折しない OAuth/OpenID Connect 入門・API を守る認証・認可フローのしくみ」と題し、Authlete 代表の川崎貴彦が寄稿しました。 本プレゼンテーションでは記事のポイントや、理解を深めるために重要なポイントについて、著者の川崎がお話しします。 文字起こし はじめに 目次 記事の第1章、第2章、第3章は、こういう目次になっています。 ここからピックアップして、 こんなことを話してます、というところを、 紹介したいと思います。 自己紹介 Au
アプリケーションにおける権限設計の課題 - kenfdev’s blog
日々権限設計で頭を抱えてます。この苦悩が終わることは無いと思ってますが、新しい課題にぶつかっていくうちに最初のころの課題を忘れていきそうなので、現時点での自分の中でぐちゃぐちゃになっている情報をまとめようと思い、記事にしました。 所々で「メリット」「デメリット」に関連する情報がありますが、そのときそのときには色々と感じることがあっても、いざ記事にまとめるときに思い出せないものが多々ありました。フィードバックや自分の経験を思い出しながら随時更新する予定です。 TL;DR（長すぎて読みたくない） 想定する読者や前提知識 この記事での権限とは 権限の種類 ACL(Access Control List) RBAC(Role-Based Access Control) ABAC(Attribute-Based Access Control) どの権限モデルを採用するべきか 権限を適用する場面 機能
『いまどきの OAuth / OpenID Connect (OIDC) 一挙おさらい』の予習・復習用情報 - Qiita
はじめに Authlete（オースリート）社主催の勉強会『いまどきの OAuth / OpenID Connect (OIDC) 一挙おさらい』（2020 年 1 月 31 日（済）, 2020 年 2 月 21 日（中止））の内容がてんこ盛り過ぎるため、予習・復習用の情報を書き出そうと思います。 追記 2020 年 1 月 31 日の勉強会の資料と動画（字幕付き）を公開しました！ OAuth / OIDC 勉強会参加者は、OAuth 2.0（オーオース）と OpenID Connect（オープンアイディー・コネクト）の基本を知っていることが前提となります。 OAuth 2.0 は「アクセストークンを発行する仕組み」です。その中心となる仕様は RFC 6749 です。詳細については『一番分かりやすい OAuth の説明』と『OAuth 2.0 全フローの図解と動画』をご参照ください。 Op
OAuth2 offline_accessスコープ対応 - Chatwork Creator's Note
こんにちは、かとじゅんです。 今回はOAuth2のスコープに offline_access という新しいスコープが追加されたので以下にお知らせします。ひとことで言うと、チャットワークと連携するBOTを作りやすくするスコープです！ 詳しくはこちらを参照ください。 チャットワークAPIドキュメント 用語の定義 まず目的を説明する前に、用語の定義から説明させてください。 offline_accessのoffline(オフライン)とは、リソースオーナー(チャットワークユーザー)が、OAuth2クライアント(以下、クライアント)上で不在の状態のことを指します。逆はオンラインと呼びます。わかりにくければ、オフラインがログアウト状態、オンラインがログイン状態と考えて差し支えありません。つまり、offline_accessとは、リソースオーナーのオフライン時でも、クライアントがチャットワーク APIにアク
response_mode=web_messageを調べた - Qiita
概要 response_mode=web_message がわからなかったので、さくっとわかる範囲で調査をしてみた。ざっくりまとめると以下の理解。 SPA(Single Page Application) で prompt=none を使ったセッション確認が画面遷移を発生させずに行える 通常だと /authorize のレスポンスでリダイレクトが発生してしまうが、それだと SPA の利点が損なわれてしまう response_mode=web_message をつけることで、リダイレクトを発生させずに認可コードを取得することができる この資料がとてもわかりやすかった。私のざっくりした説明より詳細が書いてあるので、もう少し理解したい人はこれを読もう。 OAuth 2.0 Web Messaging Response Mode - OpenID Summit Tokyo 2015 そもそも re
マイクロサービスでの認証認可 - Qiita
複数のクラウドサービスを利用している（マルチクラウド）など、単純には閉域網を構築できない環境でマイクロサービスアーキテクチャを採用する場合には、サービス間の認証認可が必要となる。この場合のサービス間の認証認可方式を決める参考となる、OSSやSaaS、Webサービスで採用方式ついて整理した。 Istio サービスメッシュの実装として有名なIstioではサービス間通信を以下のように制御できる。 Istioの認証認可では認証主体がService Identityというモデルで抽象化され、KubernatesやIstioで定義するService Accountに加えて、GCP/AWSのIAMアカウントやオンプレミスの既存IDなどをService Identityとして扱うことができる。 サービス間の認証 (Peer Authentication) は、各サービス (Pod) に設置するSideca
PKCE で防げる「認可コード横取り攻撃」とはどのような攻撃か - Qiita
「どうすればそれを実装できるか？」は理解に易くても、 「何故そういう仕組みになったのか？」といったところに焦点を当てた丁寧な解説って、あまりなかったりしますよね。 自分自身、残念ながら腑に落としきれないまま実装することが少なくなかったり、 世の中に出回っているサービスでも、 仕様の意味をきちんと理解されていないのかパラメータが本来の目的で使われておらず隙が発生してしまっているものが存在したり･･･。 ということで、 PKCE について、自分が知っている範囲でメモ残しておこうと思います。 本来あるべきを考える PKCEとは？ PKCEは、OAuth 2.0 の拡張仕様で、 Public Client が被り得る「認可コード横取り攻撃」を防ぐためのものです。 ぴくしーと読みます。OAuthのセキュリティを守る妖精さん 仕様はこれ Proof Key for Code Exchange by O
PKCE: 認可コード横取り攻撃対策のために OAuth サーバーとクライアントが実装すべきこと - Qiita
PKCE とは PKCE をご存知でしょうか？ これは、今から一年ほど前の 2015 年 9 月に RFC 7636 (Proof Key for Code Exchange by OAuth Public Clients) として公開された仕様を指しています。認可コード横取り攻撃 (authorization code interception attack) への対策として策定されました。 細かい条件は幾つかありますが、スマートフォンで OAuth クライアントを作る場合は、クライアント側も認可サーバー側もこの仕様の実装が強く推奨されます。これを実装しておかないと、悪意のあるアプリケーションに認可コードを横取りされてしまい、結果、悪意のあるアプリケーションがアクセストークンを取得できてしまいます。 この仕様自体のちょっとした解説は、「OAuth & OpenID Connect 関連仕
graphql-rubyを使って認可する方法 - Qiita
GraphQLを使っているときに様々な処理で認可させたい事があると思います。 このQueryはログインユーザーのみ実行できるようにしたい このMutationは管理者のみ実行できるようにしたい このQueryは自分の所有しているデータのときだけ返却するようにしたい このFieldは自分の所有しているデータのときだけ返却するようにしたい 当初はgraphql-rubyの知識が乏しかったので取得や更新処理の中で認可する処理を呼び出していたのですが、graphql-rubyのドキュメントを改めて読み直したところ、認可のためのメソッド(authorized?)がある事がわかったので動作検証を兼ねて記事を書きました。 2021/02/10 追記 コメントでいただきましたが、類似のメソッドにready?というものがあるようです。 ドキュメントにも記載されています。 https://graphql-ru
OAuth vs SAML vs OpenID Connect vs SSO それぞれの違い。
OAuth vs SAML vs OpenID Connect vs SSO それぞれの違い。 2020.06.16 社内勉強会 はじめに この記事は株式会社digglueの新卒を含む社員向けの勉強会で利用した内容です。今回のテーマ「OAuth, SAML, OpenID Connect, SSOの違い」です。内容や表現の間違いなどがあるかもしれませんがご了承ください。 学習の目的 OAuthやActive Directoryなどのシングルサインオンの認証について理解を深めようとすると、SAML, OAuth, OpenID Connect, SSOなどの関連性のある用語が多く出てきて混乱します。今回はこれらの用語を比較し、認証についての理解を整理します。 SSO(シングルサインオンとは) 1度のログインにより複数のサービスはアクセスするための仕組みがSSOです。SAML, OAuth,
GraphQLにおける認証認可事例（Auth0 RBAC仕立て） - Qiita
お題 以下の組み合わせで作成しているWebアプリケーションにAuth0による認証認可機能を入れてみる。 認証はID（メールアドレス）とパスワードによる方式を採用。 ■通信方式 ・GraphQL ■フロントエンド ・Vue.js ・Nuxt.js ・TypeScript ・Apollo ■バックエンド ・Golang ・gqlgen 挙動としては以下のようになる。 （１）ログイン前。「LOG IN」ボタンを押下する。 （２）Auth0のログイン画面（カスタマイズもできるらしい）に飛ばされる。メアドとパスワードを入れて「Continue」ボタンを押下する。 （３）認証が通るとアクセストークン付きでコールバック（あらかじめAuth0に設定しておく）が呼ばれる。 （４）ログイン後のトップ画面を表示する。 （５）サイドメニューから「Movie」を選択して動画一覧ページに遷移する。 （６）ログインユー
Microservices における認証と認可の設計パターン
マイクロサービスにおける認証と認可の、一般論としての設計パターンを調べたところ、Web 上の複数の記事で似たようなパターンが登場していた。ここでは、まず認証と認可が実現したい一般的な要件と、そのマイクロサービスでの難しさを整理し、認証と認可に分けて調査したパターンをまとめた。 あくまで “一般論” なので、実際には個々のドメインにあわせてアレンジが必要 往々にしてこの “アレンジ” に価値が宿るものだが、まずはセオリーを知っておきたいというモチベーションで調査した Web 上の記事を読んでまとめただけなので、手を動かしての確認はしておらず、理解が甘い部分はご容赦ください 具体的な通信方式やサービス間通信のセキュリティといった具体論までは踏み込めていない。このへんはサービスメッシュやゼロトラストネットワークといったトピックが登場すると思われる これらは次回以降の Todo としています その
認証プラットフォーム Auth0 とは？ - Qiita
2017/06/28にドコモベンチャーズがAuth0に出資をしたというニュースが流れましたが、Auth0とはどんな会社で、どんなサービスを提供していのでしょうか？ Auth0とは Auth0 Inc.は2013年に米国Microsoftに在籍していたメンバーを中心に創業した会社で、Washington州Bellevueに本社があります。創業メンバーはEugenio Pace(CEO), Matias Woloski(CTO) などMicrosoftに在籍していたメンバーのほか、Node.jsの認証フレームワークである"Passport"の開発者であった Jered Hanson, AT&T, Amazon.com, 国防総省での勤務経験のある Eugen Koganも創業メンバーです。 Auth0 統合認証プラットフォーム Auth0はWebアプリやモバイル、APIなどに対して認証・認可の
よくわかる認証と認可 | DevelopersIO
よく訓練されたアップル信者、都元です。「認証 認可」でググると保育園の話が山程出て来ます。が、今日は保育園の話ではありません。そちらを期待した方はごめんなさい。こちらからお帰りください。 さて、先日のDevelopers.IO 2016において、マイクロWebアプリケーションというテーマでお話させて頂きました。一言で言うと OAuth 2.0 と OpenID Connect 1.0 のお話だったのですが、これらを理解するにあたっては「認証」と「認可」をはっきりと別のものとしてクッキリと認識する必要があります。 まず、ざっくりとした理解 認証と認可は密接に絡み合っている一方で全く別の概念です。正直、理解は簡単ではないと思います。 まず「認証」は英語では Authentication と言います。長いので略して AuthN と書いたりすることもあります。意味としては 通信の相手が誰（何）であ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
認証と認可の超サマリ OAuth とか OpenID Connect とか SAML とかをまとめてざっと把握する本