図解：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の実装手法を紹介し
HTTPS でも Full URL が漏れる？OAuth の code も漏れるんじゃね？？ - OAuth.jp
なんですかこれは！ 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 /
バグバウンティ（BugBounty）はじめました - kubell Creator's Note
こんにちは。モンハンは弓か片手剣の田中です。 弊社ChatWorkでは昨年からバグバウンティの導入をし、先月報奨金制度をスタートさせました。 ChatWork BugBounty.jp - バグバウンティ・プラットフォーム 今回は、バグバウンティ導入についてのあれこれを書いておきたいと思います。 導入に至った背景 弊社が運営している「チャットワーク」は現在導入社数が16万社を超え、おかげさまで広く使われるようになりました。 しかし、サービスが成長すると同時に、セキュリティをどう担保していくかという課題がでてきました。 Webサービスを運営している以上、セキュリティ対策はその運営会社の一つの責任であり、出来る限り脆弱性によるリスクは小さく保っていきたいです。 日々の業務、新規機能開発との両立をどうしていくか・・・その一つの回答がバグバウンティでした。 バグバウンティとは？ バグバウンティとは
Google Identity | Google for Developers
Sign In with Google SDKs Credential Manager for Android Sign In with Google for Web (including One Tap) Google Sign-In for iOS and macOS Industry standards Passkeys OpenID Connect Legacy Sign In One Tap sign-up/sign-in for Android Google Sign-In for Android Google Sign-In for Web Call Google APIs Authorizing for Android Authorizing for Web Authorizing for iOS/macOS Using OAuth 2.0 Share data with
OAuth & OpenID Connect 関連仕様まとめ - Qiita
はじめに OAuth や OpenID Connect に関連する仕様を紹介していこうと思います。 仕様はたくさんあるものの、ほとんどオプショナルです。しかし、「認可サーバーを実装する際は、RFC 6749 だけではなく、認可コード横取り攻撃への対抗策である RFC 7636 も実装すべきである」* という点は強調しておきたいと思います。 * 「PKCE: 認可コード横取り攻撃対策のために OAuth サーバーとクライアントが実装すべきこと」という記事もご参照ください。 1. OAuth 2.0 (RFC 6749) OAuth 2.0 の仕様の本体は RFC 6749 (The OAuth 2.0 Authorization Framework) です。RFC 6749 の解説記事は世の中にたくさんあるので、ここでは要点だけ手短に紹介します。 RFC 6749 は、アクセストークンを発行
Home - Authlete
“OAuth/OIDC Component as a Service” Authlete's APIs are carefully crafted to focus on the core of OAuth 2.0 / OpenID Connect (OIDC). You can choose to build a complete OAuth/OIDC server with Authlete, or simply integrate Authlete with existing service components such as identity and access management (IAM) and API gateways. Just Forward OAuth/OIDC Requests to Authlete You don't have to evaluate cl
OpenID Connectはそんなに大変かね？ - OAuth.jp
OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る – Qiita ってのになんかフォローアップしろよ的なのが来たので。 ざっと読んだ感想としては、「OpenID Connect の OPTIONAL な機能全部実装したら、そら大変ですね」という感じ。（Authlete に関しては、OpenAM みたいな感じで使われる、OpenAM よりはるかに簡単に使える代わりに有料の何かなんだろうな、というイメージです） OAuth は必要なのか？ Basic 認証は死んだ。 ユーザー単位での API のアクセスコントロールがしたいです。 っていう前提で話すると、OAuth 以外まともな選択肢が無いんじゃないでしょうか。 OAuth の各種 Extension (RFC 6749 & 6750 以外にいろいろある) に関しては、適宜必要なのを実装すればいいんだけど
Domain Modeling with Functions - an algebraic approach
The document discusses domain modeling using an algebraic approach with functions. It explains that a domain model describes entities, attributes, roles, relationships and constraints in a problem domain. It advocates modeling the domain as an algebra of types and functions, with types representing entities and functions representing behaviors. This approach uses algebraic data types to define imm
webサイト訪問者に一度だけスーパーリロードをしてもらう - Qiita
ポイントはtrue。 location.reload();は現在のページを読み込み直すJavaScript。 trueの値を指定すると、ブラウザのキャッシュを使わずにサーバーからデータを取得してくれるようになる。 詳細はwindow.location - Web API インターフェイス | MDN辺りを参照。 「一度だけ」実行する docCookies.setItem("temp", "true"); //適当なcookieの書き込みを行い、 if("true" == docCookies.getItem("temp")){ //正常に利用できる環境であれば実行 if("true" != docCookies.getItem("refresh")){ //初回訪問時は実行される docCookies.setItem("refresh", "true"); //2回目以降は、cookieに
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Mitigate Replay Attacks When Using the Implicit Flow
Amazon API Gateway