Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに Authlete（オースリート）社主催の勉強会『いまどきの OAuth / OpenID Connect (OIDC) 一挙おさらい』（2020 年 1 月 31 日（済）, 2020 年 2 月 21 日（中止））の内容がてんこ盛り過ぎるため、予習・復習用の情報を書き出そうと思います。 追記 2020 年 1 月 31 日の勉強会の資料と動画（字幕付き）を公開しました！ OAuth / OIDC 勉強会参加者は、OAuth 2.0（オーオース）と OpenID Connect（オープンアイディー・コネクト）の基本を知っている
0x00 背景 一 Web Pentester の立場から、毎回 OAuth 連携の案件が来る時に、どこが診断する必要なのか、どこが idP の SDK 使っているから診断不要なのかを見極める必要があり、このような背景において、OAuth2.0 をもう一回復習して、心得を共有したいと思い始めました。（0x01~0x08）。復習しているうちに、OAuth の idP 両社の脆弱性を見つけ、50万円賞金もらって終わりと思ったらいつの間に両社経営統合されました。この話を読みたい方は 0x09 から読んでください。 この文章を読む前提は二つあります： OAuth2.0 の各種認証 Flow (すくなくとも Implicit Grant, Code Grant, Code Grant with PKCE) を大まかに理解していること。 この文章図解：OAuth 2.0に潜む「5つの脆弱性」と解決法に
おはようございます、OAuth警察を装っている ritou です。 qiita.com 認証認可技術 Advent Calendar 2019 2日目の記事です。 今日もやっていきましょう。 (2020/3/9追記)本投稿の内容をさらにわかりやすく整理された本を @authyasan さんが書かれています。 #技術書典 応援祭の新刊をBOOTHで公開！ OAuth・OIDCへの攻撃と対策を整理して理解できる本（リダイレクトへの攻撃編 https://t.co/OtNRNQGmOJ 以下について学びたい方はぜひお読みください state nonce PKCE c_hash at_hash CSRF リプレイ攻撃 認可コード横取り攻撃 トークン・コードインジェクション— Auth屋@技術書典応援祭を応援！OAuthへの攻撃本執筆中 (@authyasan) 2020年3月7日 私もレビューをさ
逆に、RFC 6749 以外で定義されている認可フローをサポートする場合、新たに別のエンドポイントの実装が必要になることがあります。例えば CIBA（Client Initiated Backchannel Authentication）では**バックチャネル認証エンドポイント（backchannel authentication endpoint）、デバイスフロー（RFC 8628）ではデバイス認可エンドポイント**（device authorization endpoint）の実装が求められます。 この記事では、認可エンドポイントとトークンエンドポイントを実装します。サポートする認可フローは認可コードフローのみ、サポートするクライアント・タイプはパブリックのみとします。 2. 注意点 下記の理由、および書かれていないその他の理由により、本実装は商用利用には適していません。 セキュリティ
次世代 Web カンファレンス 2019に行ってきました。 各発表の感想 全部パネルディスカッションなので自分が見てきたセッションのメモでお送りします。あとで録画が出るのでちゃんと見たいかたはそちらを御覧ください。また登壇者はconnpassなどをご参照のこと。 SRE www.youtube.com twitter.com トークまとめ お三方個別に意見を喋られてましたが、まとめたダイジェスト風になります。 行う業務の比率に関して リアクティブとプロアクティブという形でタスクを分ける手法をとっていて、それらが50%ずつになる運用をしている リアクティブとは差し込みやアラート対応などの業務 プロアクティブとはモニタリングの改善などもともと計画的にやろうとしてた業務 SRE本のトイル（toil)とリアクティブは同じ意味だが、言葉が強すぎる ロードマップを敷いて、それ以外の差し込みタスクという
JOSE (Javascript Object Signing and Encryption) 愛で満ち溢れる ID 厨界隈において、燦々と輝く JWS (JSON Web Signature)、美しいですよね！ JWT がジャニーズなら、JWE は EXILE、JWS は石原さとみと言ったところでしょうか？ と、冗談はさておき、JWT をお使いの皆さんは、当然署名付けてますよね？署名検証しますよね？ そんなあなたに一言いいたい！ まだ HMAC で消耗してるの？ いや、決して HMAC オワコンとかは言ってないですよ？スマホアプリでの署名検証のために、アプリに共通鍵埋め込むのはナンセンスってだけで。 ということで、今日は JWS をお使いのみなさんに、実装時に作りがちな脆弱性パターンを2つご紹介します。 今日紹介する脆弱性の2つのうち、1つめは HMAC, RSA, ECDSA のどれを
認証を持たないウェブアプリケーションをいざ認証に対応させようと思うと案外面倒でモチベーションを無くしてしまうなんて事もよく起きうる話です。特に社内向けのアプリケーションを作っていたら本番で使う事になってしまって、なんて話は良くある話です。開発で本番 DB を見るのはちょっと...。でも既存のコードをゴリゴリと触りたくない。そんな場合にログイン認証部分だけマイクロサービス化できると気持ちも幾分和らぎます。今日はそんなちょっと便利なサーバ「loginsrv」を紹介したいと思います。 GitHub - tarent/loginsrv: JWT login microservice with plugable backends such as OAuth2, Github, htpasswd, osiam loginsrv is a standalone minimalistic login se
この記事は、 Advent Calendar 2016 - VOYAGE GROUP techlog の16日目のエントリです！ みなさんこんにちは！ VOYAGE MARKETINGにてエンジニアをしている なかにしごう (@gomachan46) | Twitter です。 2014年より社内非公式サークルとして 音ゲー部 を立ち上げ、お昼休みは会議室のプロジェクターで音ゲー鑑賞、定時後はゲームセンターで練習と、現在もなお元気に活動しています。 さて、今回はタイトルの通り WebSocketを用いた全く新しいOAuth をご紹介したいと思います。 ご存知の方も多いとは思いますが、さらっと簡単に用語の説明をしていこうと思います。 WebSocket WebSocket（ウェブソケット）は、コンピュータ・ネットワーク用の通信規格の1つである。インターネットの標準化団体であるW3CとIETF
8月3日のBlackhat 2016で発表された、HTTPSのURLが読めるというWPAD/PAC Attack1、なるほどねぇ、と思わせるアタックですな。 HTTPS自身を攻撃するわけじゃなくて、HTTPSのhostに対するproxy resolveの時に、PACファイルを使ってURLの内容をフィルタリングして攻撃者のホストに送るというやり口。 毎回proxy resolveが走るブラウザ（例：Firefox, Chrome）とそうでないブラウザがあって、後者だとあまり攻撃は成功しないが、FirefoxやChromeなどでは効果的。ただし、LANのProxy設定などで、「設定を自動的に検出する」がオンになっていなければならない。でもこれは、企業システムなどでは割りとONになっていることが多いのではないだろうか。
なんですかこれは！ New attack bypasses HTTPS protection on Macs, Windows, and Linux DHCP につなぐと PAC ファイルがダウンロードされて HTTPS であろうとアクセス先の Full URL は漏れるですって？ Web Proxy Autodiscovery ですって？ チョットニホンゴデオネガイシマス ってことで、まぁこれが実際どれくらい簡単に実現できる攻撃パターンなのかは他のセキュリティ業界の方々に後で聞くとして、この記事でも触れられてる OpenID Connect とか OAuth2 への影響について、ちょっとまとめておきましょうか。 Authorization Request & Response が漏れる response_mode=form_post なんていうのも一部ありますが、基本 OAuth2 /
「nginx で omniauth を利用してアクセス制御を行う」という記事で、 ngx_http_auth_request_moduleの存在を知ったので、 Golangでnginx_omniauth_adapterと似たようなものを作ってみました。 shogo82148/go-nginx-oauth2-adapter 背景 typester/gateは単体でも動くようになっていますが、 例えばIP制限などちょっと高度なことをしたい場合には結局nginxを前段に置く必要があります。 nginxとgateの設定を同時にいじる必要があって煩雑だと感じていました。 そんな中「nginx で omniauth を利用してアクセス制御を行う」という記事で、 ngx_http_auth_request_moduleの存在を知りました。 gateが認証＋Proxyをやってしまうのに対して、認証だけRu
oauth2_proxy、便利でググると導入手順も結構出てくるのだけど、今回紹介するのは（環境によっては）さらに便利に使えるナウい方法です。 なにをするのかというとREAMDEに書いてあります。 Configuring for use with the Nginx auth_request directive The Nginx auth_request directive allows Nginx to authenticate requests via the oauth2_proxy's /auth endpoint, which only returns a 202 Accepted response or a 401 Unauthorized response without proxying the request through. For example: サンプル設定もある
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、ID連携黒帯 倉林 雅（@kura_lab）です。 昨年の「知っておきたい7つのID連携実装パターン」に続き今年も23日を担当することになりました！祝日も記事を投稿いたします！ 今年のAdventCalendarも「Yahoo! JAPANを支える技術」をテーマとしていますが、今回は少し先の未来をみすえて今後Yahoo! JAPANを支えることになるかもしれない新しい技術についてご紹介しようと思います。 すでにPCやスマホ上で認証を行いサービスを利用することは普通になりつつありますが、今後はテレビやゲーム機、ビデオカメラなどのデバイスでも認証や決済を利用したサービスが増えてくると思われます。Identity Provi
production: &production facebook: key: xxxxxxxxxxx secret: XXXXXXXXXXXXXXXXXXXXXXXXX github: key: xxxxxxxxxxx secret: XXXXXXXXXXXXXXXXXXXXXXXXX google: key: xxxxxxxxxxx secret: XXXXXXXXXXXXXXXXXXXXXXXXX hatena: key: xxxxxxxxxxx secret: XXXXXXXXXXXXXXXXXXXXXXXXX linkedin: key: xxxxxxxxxxx secret: XXXXXXXXXXXXXXXXXXXXXXXXX mixi: key: xxxxxxxxxxx secret: XXXXXXXXXXXXXXXXXXXXXXXXX twitter: key: xxxxxx
OAuth って言われたら、大体の人は Facebook でログインとかを選ぶと、「〜があなたの以下の情報にアクセスしようとしています」みたいな文章が出てきて OK するやつを想像すると思います。 実は OAuth には、上記のフロー以外にも、アプリケーションにユーザのリソースへのアクセスを認可するためのフローが存在します。 今回 OAuth と doorkeeper についていろいろ調べたので、備忘録も兼ねて各認可フローを簡単に説明しつつ、doorkeeper gem を使って OAuth の各認可フローを試してみます。 補足： 本投稿中の OAuth とは、すべて RFC 6749 で定められている OAuth 2.0 のことです。 理解不足＆説明を簡単にするために正確でないことがあるかもしれませんので、詳細については参考に挙げたページをご確認ください。OAuth に詳しい方はぜひいろ
OAuthプロバイダを提供することになったとして、アクセストークンに有効期限を設けるべきかどうかについて考えたい。OAuth 2.0の仕様にはアクセストークンの期限切れに関係する仕様が定義されているし、セキュリティをより強固にするためにアクセストークンは一定期間で期限切れにするべきだという主張があったと思う (確認していないので無いかもしれない)。しかしながら、例えばGitHub API v3ではアクセストークンに有効期限を設けていない。この投稿では、アクセストークンの有効期限に関係して起こり得る問題を取り上げる。 アクセストークンに有効期限を持たせておくとちょっと安全 アクセストークンが悪意のある第三者に漏洩してしまった場合、そのアクセストークンに認可されているあらゆる操作が実行可能になってしまうという問題がまず存在する。ここでもしアクセストークンに有効期限が存在していたとすれば、その操
Google認証なリバースプロクシ＆静的コンテンツ配信サーバー「gate」 - unknownplace.orgで紹介されている、typesterさんのgateという、GoogleのOAuth2認証付きプロキシサーバがとても便利そうだったので、即座に使いたくなった。 これは、昨今増えつつあるメトリクス系のツールだとかの、インターネット上に置きつつも、社内のみに提供したいサービスを立てるに際して、フロントにnginxをおいた場合に、認証のことを考えるのがだるい、というか、nginxの設定自体がだるいみたいなときに役立つツールです。その際、自分とこ的にはGitHubのorganizationでアカウント管理できるとさらによいので、GitHub対応をしてpull requestを送ったところmergeされました。ありがとうございます。 会社で運用しているorganizationがfoo_orga
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
