FAPIとKeycloakの概要
連載の1回目である今回は、FAPIの概要並びに、IAMのKeycloakのFAPI対応について紹介します。 はじめに サービスデリバリのアジリティを高めるために、今やサービス開発にAPIを利用することは必要不可欠となっています。また既存サービスに新たな価値を付与するために、APIを公開することも常套手段の一つとなっています。このようにAPIに触れる機会が日常にあふれている一方、APIに対して適切なセキュリティ設計を行わなかったために、機密性の高い情報が漏えいしてしまったり、金融取引に関わる不正操作を許してしまったりという事故や事件は後を絶ちません。攻撃者による攻撃が日々進化をし続けている中、APIを公開するシステムに求められるセキュリティ要件は日々高度化しています。 そんな中で注目を集めているのが、Financial-grade API Security Profile（以下、FAPI）で
PKCE で防げる「認可コード横取り攻撃」とはどのような攻撃か - Qiita
「どうすればそれを実装できるか？」は理解に易くても、 「何故そういう仕組みになったのか？」といったところに焦点を当てた丁寧な解説って、あまりなかったりしますよね。 自分自身、残念ながら腑に落としきれないまま実装することが少なくなかったり、 世の中に出回っているサービスでも、 仕様の意味をきちんと理解されていないのかパラメータが本来の目的で使われておらず隙が発生してしまっているものが存在したり･･･。 ということで、 PKCE について、自分が知っている範囲でメモ残しておこうと思います。 本来あるべきを考える PKCEとは？ PKCEは、OAuth 2.0 の拡張仕様で、 Public Client が被り得る「認可コード横取り攻撃」を防ぐためのものです。 ぴくしーと読みます。OAuthのセキュリティを守る妖精さん 仕様はこれ Proof Key for Code Exchange by O
OAuth2 PKCE対応について - Chatwork Creator's Note
かとじゅん(@j5ik2o)です。OAuth2を使った、チャットワークAPI開発者向けのリリース情報です。 今回は、RFC7636 PKCE(=Proof Key for Code Exchange by OAuth Public Clients)をリリースしました*1。 ただ、API ドキュメントの修正が間に合っていないので、後追いで修正させていただきます。また、現状のPKCEの実装には一部制限がありますので、開発者の方は最後までこの記事に目を通していただけると助かります。 PKCEとは、認可コード横取り攻撃対策のためのOAuth2の拡張仕様です。詳しくは以下のブログ記事などを参考にしてください。 qiita.com qiita.com 簡単に説明すると、Authorization Code Flowで「ブラウザ上のJSやモバイルアプリなど」のパブリッククライアント*2を認可させるための
アクセストークンに有効期限を設けるべきかどうか - Qiita
OAuthプロバイダを提供することになったとして、アクセストークンに有効期限を設けるべきかどうかについて考えたい。OAuth 2.0の仕様にはアクセストークンの期限切れに関係する仕様が定義されているし、セキュリティをより強固にするためにアクセストークンは一定期間で期限切れにするべきだという主張があったと思う (確認していないので無いかもしれない)。しかしながら、例えばGitHub API v3ではアクセストークンに有効期限を設けていない。この投稿では、アクセストークンの有効期限に関係して起こり得る問題を取り上げる。 アクセストークンに有効期限を持たせておくとちょっと安全 アクセストークンが悪意のある第三者に漏洩してしまった場合、そのアクセストークンに認可されているあらゆる操作が実行可能になってしまうという問題がまず存在する。ここでもしアクセストークンに有効期限が存在していたとすれば、その操
Facebook APIで項目が取得できない！パーミション(権限）についてまとめてみた | サイト構築日記
Facebook APIを使って、ログインしているユーザさんのプロフィール情報を取得しようとしたら一部の情報が取得できない！ということがありました。いろいろ調べたので備忘録します。 やろうとしたことはユーザさんの新規会員登録をFacebookログインから行うというよくある内容です。紐づけたあと新規登録の入力画面で名前などを入力してもらうのですが、そのときFacebookから取得できるユーザ情報は、できるだけはじめから補完しておきます。 サンプル事例 例として次のような流れを考えてみます。 クライアント（自社サイト）に「Facebookで新規会員登録ボタン」を配置します。 ユーザさんはそのボタンをクリックし、しばらくはFacebookとのやり取りが続きます。 ユーザさんがクライアントに情報を渡して良いと承認を出せば、Facebookはアクセストークンをクライアントに渡します。 ここまでは、「
【Rails5】Doorkeeper gemでOAuth2.0のためのAPIを作って、rubyクライアントで呼び出す - daily-dev.net
DooerkeeperはOAuth 2のプロバイダ（認証する側のサーバー）を簡単に実装できるgemです。 意外とハマったので書いておきます！ Doorkeeper gemをインストール github.com #Gemfile gem 'doorkeeper' gem 'doorkeeper-i18n' # default localeを en 以外で使うなら #terminal rails generate doorkeeper:install rails generate doorkeeper:migration #active record 使うなら rake db:migrate routes.rb Rails.application.routes.draw do use_doorkeeper #追加 end ↑で以下のルートが生成されます. GET /oauth/authorize
RFC7662: OAuth 2.0 Token Introspectionでアクセストークンの検証を行う - Qiita
はじめに API認証にOAuth2を使う場合、認可サーバでアクセストークンを発行して、リソースサーバ(APIサーバ)にアクセストークン付きでリソースをリクエストするわけですが、認可サーバとリソースサーバが分かれてる場合、アクセストークンをリソースサーバで受け取ったあとに、このトークンは正しいのか？どのようなスコープが許可されているのか？どうやって確認すればよいんだろうかという疑問が湧いてきます。 OAuth2そのものの「RFC6749: The OAuth 2.0 Authorization Framework」では仕様の範囲外として記載されていませんが、調べたところ、OAuth2の拡張仕様で、以下の選択肢があるようです。 RFC7662: OAuth 2.0 Token Introspection RFC7662は認可サーバのトークン確認用エンドポイントにリクエストを送信し、レスポンスと
OAuth2.0を利用するネイティブアプリの注意点 - 理系学生日記
OAuth 2.0 をスマートフォンのネイティブアプリに提供することになりそうだったので、この一週間くらい RFC を読み続けていました。 しかしですね、Web アプリケーションが OAuth 2.0 のクライアントとなるケースは想像できるようになったんだけど、iPhone アプリに代表される Native App を OAuth 2.0 に対応させるケースがなかなか想像できない。 それでも色々調べて調べて、ようやくどういう形で実現されるのかが分かってきたので、ここでまとめてみます。 OAuth 2.0 の概要 いろいろ読んでみたけど、OAuth 2.0 の概要だったらこの 2 つの RFC を読めば良いと思います。 RFC 6749 - The OAuth 2.0 Authorization Framework RFC 6750 - The OAuth 2.0 Authorization
チュートリアル: OAuth 2.0 を使用した API の保護
既存のエンドポイントを呼び出す API 定義を操作するために IBM® API Connect デベロッパーズ・ツールキットのチュートリアルで行う作業の流れを以下の図に示します。チュートリアルを開始する前に、そのチュートリアルより順序が前のチュートリアルを完了する必要があります。図のチュートリアルをクリックすると、そのチュートリアルの説明が開きます。 このチュートリアルについて チュートリアルチュートリアル: REST API 呼び出し定義の作成で作成した支店 API のセキュリティー設定を変更して、呼び出し側のアプリケーションが OAuth 2.0 を利用して、ユーザーのパスワードを必要とせずにそのユーザーの代わりに API にアクセスできるようにします。 このチュートリアルでは、以下のレッスンを行います。 OAuth スキームの選択 OAuth 2.0 プロバイダー API の作成 A
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 関連仕
OAuth2.0で認可コードの漏洩を防ぐPKCE - 理系学生日記
OAuth 2.0 における通信は基本的に TLS で守られるのが基本なのだけれど、ひとつ TLS で守られない通信があります。それは Client・User-Agent 間の通信です。 Authorization Code Grant においては、認可サーバから認可コードを受けた User-Agent がその情報をクライアントに渡すときに発生します。 Authlete via kwout Authlete さんの以下の図がすごくわかりやすいのですが、User-Agent (Operation System Browser) から Malicious App に認可コードが漏れていることがわかります。 Native App では、これは Custom Scheme が悪意のある App に上書きされた場合等で発生します。 もちろん、認可コードが漏れたら、アクセストークンも漏れるので、このよ
OAuth for Native Apps | GREE Engineering
GREE Advent Calendar 9日目は @nov が担当します。 僕は GREE ではセキュリティ部に所属しており、社外では OAuth や OpenID Connect などの Identity 関連技術についての翻訳や講演などを行ったりもしています。 今日は GREE Advent Calendar ということで、Native App コンテキストでの OAuth の話を少し書いてみようと思います。 はじめに Native App を開発していると、Backend Server とのやりとりや Facebook Login や Google Sign-in などで、必ずと言っていいほど OAuth 2.0 というのが出てきます。 OAuth 1.0 と異なりリクエストに署名が不要だったり、Client Secret (a.k.a Consumer Secret) 無しでも
OAuth 2.0 の仕様を読むために - Qiita
OAuth 2.0に関しては、いろんな解説や実装がありますが、結局、http://tools.ietf.org/html/rfc6749 にあるRFCの仕様を読むのが一番なのではないかと思い、それを読む際に必要な部分、詰まりやすい部分をまとめてみました。 OAuth 2.0 の公式サイト (http://oauth.net/2/) もRFCは1行で軽くリンクがあるだけで、どうせ皆各言語で実装したライブラリが知りたいんでしょみたいな構成になっていますが、自社もAPIを公開しようとか、マイクロサービスアーキテクチャをしっかり構築しようなどという時に、Resource Server側になることも最近はすごい珍しい訳でも無いのかなと思います。 意外とちゃんと訳しておいたほうが良い英単語 例えば、Authorization=認証みたいに思っていると意味を誤解しやすいので、きちんと日本語訳の対応付けを
WebViewでGoogleアカウントのOAuth認証が使えなくなる問題｜TechRacho by BPS株式会社
はじめに こんにちは、hachi8833です。 Google Developers Blogに先週公開された記事「Modernizing OAuth interactions in Native Apps for Better Usability and Security」で､WebViewからのOAuthで行うGoogleアカウントの認証を今後廃止するとの記述がありました｡記事の中でも特にシビれるのが「web-viewには、AndroidのWebView UI 要素、iOSのUIWebViewやWKWebViewのほか、WindowsやOS X上の同等の機能も含まれます」という一文です｡ふわぁっとやさしく触れているのですが､どんなアプリが影響を受けるのか｡((((oﾟ▽ﾟ)o))) ﾄﾞｷﾄﾞｷ♪ 以下に取り急ぎ訳したものを参考として掲載します｡後10日もすればGoogle Develo
OpenID Foundation Japan - 翻訳・教育 Working Group
OpenID Foundation Japan 翻訳・教育 Working Group は、OpenID Foundation Japan 参加メンバーを中心に、有志により運営されています。現在は主に OpenID & OAuth 関連仕様書の翻訳活動を行っています。 翻訳ドキュメント一覧 OpenID 認証は、エンドユーザが識別子 (Identifier) を管理していることを証明する方法を提供するものである。OpenID 認証を利用すれば、リライングパーティー (Relying Party、以下 RP) はエンドユーザのパスワードやメールアドレスなどにアクセスする必要がなくなる。 OpenID Attribute Exchange は、エンドポイント間で属性情報を交換するための OpenID の拡張仕様である。ユーザーの属性情報を更新または取得するためのメッセージを提供する。 Open
rfc6749 The OAuth 2.0 Authorization Framework - OpenID Foundation Japan
Abstract OAuth 2.0 は, サードパーティーアプリケーションによるHTTPサービスへの限定的なアクセスを可能にする認可フレームワークである. サードパーティーアプリケーションによるアクセス権の取得には, リソースオーナーとHTTPサービスの間で同意のためのインタラクションを伴う場合もあるが, サードパーティーアプリケーション自身が自らの権限においてアクセスを許可する場合もある. 本仕様書はRFC 5849に記載されているOAuth 1.0 プロトコルを廃止し, その代替となるものである. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It re
Developers.IO 2017セッション「基礎からの OAuth 2.0」でお話してきました #cmdevio2017 | DevelopersIO
よく訓練されたアップル信者、都元です。クラスメソッドが運営するIT系技術ブログDevelopers.IOのカンファレンスイベントDevelopers.IO 2017にて、セッション「基礎からの OAuth 2.0」を発表しました。本エントリーはそのレポートです。 発表スライド 発表動画 セッション概要 システム開発をする以上、ほとんどの場合「認証と認可」は切っても切れない問題です。マイクロサービスが話題を集め、コンポーネントのWeb API化が急加速を見せる昨今。OAuth 2.0 という仕組みが継続的に注目を集めています。 しかし、いざその仕様を紐解いてみると Authorization code や Implicit 等、簡単には理解できない概念や選択肢が並んでおり、 自分が導入すべきなのはどのような仕組みなのか、判断が難しいのも確かです。 本セッションでは OAuth 2.0 の仕組
OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る
はじめに この文書では、OAuth 2.0 + OpenID Connect サーバーをゼロから一人で実装した開発者（私）が、得られた知見について書いていきます。基本的には「実装時に考慮すべき点」を延々と述べることになります。 そのため、この文書は、「素早く OAuth 2.0 + OpenID Connect サーバーを立てる方法」を探している方が読む類のものではありません。そのような情報をお求めの方は、「Authlete を使って超高速で OAuth 2.0 & Web API サーバーを立てる」を参照してください。そちらには、「何もない状態から認可サーバーとリソースサーバーを立て、アクセストークンの発行を受けて Web API をたたいて結果を得る」という作業を、所要時間 5 ～ 10 分でおこなう方法が紹介されています。 文書のバイアスについて 私は、OAuth 2.0 + Ope
OAuth & OpenID Connect の不適切実装まとめ - Qiita
はじめに 世の中の OAuth & OpenID Connect の不適切実装の事例をリストしています。公式ドキュメントに「ドラフト段階の仕様をサポート」と断り書きが書いてあっても、最終仕様に違反している場合はリストしています。内容は適宜更新していきます。OAuth & OpenID Connect を実装する際の注意事項として参照していただければと思います。 仕様書を読むのは面倒だけど、OAuth & OpenID Connect をちゃんと実装しないといけない立場にある方は、是非 Authlete の使用を検討してください。(by Authlete 創業者) 事例 1. リダイレクト URI を正しく検証していない John Bradley 氏の記事「Covert Redirect and its real impact on OAuth and OpenID Connect」を参照し
JSON Web Token (JWT) - OAuth.jp
@novです。 個人的に最近OAuth 2.0よりJWT (というかJWS) を利用するシーンが多く、毎回同じ説明するのもめんどくさいのでブログにまとめるかと思い、どうせならOAuth.jpに書くかということで、こんな記事を書いております。 （そろそろJWTとJWSは、OpenID Foundation Japanの翻訳WGで翻訳するべき？） JSON Web Token (JWT) とは、JSONをトークン化する仕組み。 元々はJSONデータにSignatureをつけたりEncryptionする仕組みとして考えられたものの、Signature部分がJSON Web Signatue (JWS)、Encryption部分がJSON Web Encryption (JWE) という仕様に分割された。 それぞれ2012年10月26日現在の最新仕様はこちら。 （JWTとJWSは既にだいぶ仕様が固
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
