TokenでもCookieでもBearer vs Sender-Constrained の概念を覚えよう｜ritou
こまけぇ話は置いておいて、BearerとSender-Constrainedの話がHTTP Cookieのところでも出てきたよというお話なのですが、ここを少し補足します。このBearer vs Sender-Constrainedという用語が一番出てくるのがOAuthの文脈です。 文字で読みたい2分間OAuth講座 : (1) The Basic Concepts (2) Bearer and Sender Constrained Tokens - r-weblife Bearer Token : 第1回で説明した地下鉄の切符のようなトークン。所持していれば使えるので、他の人が拾っても使えます。 Sender Constrained Token : 利用者を制限するトークン。飛行機の搭乗券のように、利用者が指定されている、制限されているもの。 概念はこんな感じですが、実装方法は色々なものが
GitHub OAuthアプリを使ったスパム攻撃を停止させる
2024年2月21日ごろから、"Github Jobs"を名乗るGitHubの開発者ポジションをオファーするスパム攻撃が発生しています。 仕組みとしては、GitHubのIssueやPRでmentionをするとメールの通知が届くのを利用して、コメントでスパムメッセージを送りつけるものです。 以前からこのスパムは存在していましたが、今回おきた問題はGitHub OAuth Appを用意して、スパムコメントで24時間以内にここから申請してくださいという感じの誘導して、OAuthアプリの認証を行わせる攻撃が含まれていました。 このスパムOAuthアプリは、GitHubのprivateリポジトリの読み取りやコメントの読み書きなどの権限も持っていたため、このスパムアプリを認可してしまうと、その人のアカウントでさらにスパムコメントが増えるという問題が起きていました。 詳細は、次のGitHub Discu
仕様が読めるようになるOAuth2.0、OpenID Connect 入門
2023/10/05 Offersさんのイベントでの資料です。 https://offers.connpass.com/event/295782/ イベント後の満足度アンケート（5点満点）の結果は以下になります。 5点: 49% 4点: 39% 3点: 8% 2点: 4% こちらのスライドの内容は以下の本の抜粋になります。デモの内容、このスライドでは触れていないことについてご興味ある場合は以下の本をご参照ください。 https://authya.booth.pm/items/1296585 https://authya.booth.pm/items/1550861 本発表で扱っていないセキュリティに関しては以下の本がおすすめです。 https://authya.booth.pm/items/1877818 本の評判 https://togetter.com/li/1477483
GitHub の OAuth 実装の仕様違反とセキュリティ上の考慮事項 - Qiita
本稿は GitHub Docs の "Authorizing OAuth Apps" ページに書かれている情報に基づいています。英語版はこちら → "Spec Violations in GitHub OAuth Implementation and Security Considerations" 仕様違反箇所 認可リクエストの response_type リクエストパラメーターがない。当パラメーターは必須である。RFC 6749 (The OAuth 2.0 Authorization Framework) Section 4.1.1 (Authorization Request) 参照。 トークンレスポンスのデフォルトフォーマットが application/x-www-form-urlencoded のようである。フォーマットは常に application/json でなければならな
FacebookからOAuthを停止されてわかった今時のセキュリティ - Uzabase for Engineers
NewsPicksの高山です。 この記事はUzabase Advent Calendar 2021の23日目の記事です。昨日は我らが赤澤剛さんによるAWS Organizationの記事でした。 去る2021年10月12日に突然NewsPicksのサービスでFacebookログインやFacebookへの投稿ができなくなりました。この状態は12月13日まで2ヶ月もの間継続していて、ユーザーさんには不便を強いてしまいました。 米Facebook本社とメールでやりとりしていましたが、メール返信に何週間も待たされ、Facebook日本法人に助けてもらってようやく解決に至ることができました。 この苦労話はいくらでもできるのですが、今回はセキュリティの切り口で書いていきます。 Facebookの「データ保護評価」 データセキュリティ項目 「すべてのプラットフォームデータストレージ(すべてのデータベース
OAuthにおける認可コード横取り攻撃とその対策
OAuthにおける認可コード横取り攻撃とその対策 Jul 5, 2021 前回の記事で示したように、カスタムURLスキームを偽装した不正アプリは正規アプリへのディープリンクを乗っ取れる。この挙動の悪用シナリオとして、正規アプリと認可サーバー間のOAuthフローにおける認可コード横取り攻撃が知られている。この攻撃への対策を把握するためにiOS環境でシナリオを再現し、PKCEの有効性を確認した。 要約 OAuth 2.0の拡張機能であるPKCEを導入することで認可コード横取り攻撃を無効化できる。OAuth 2.0の仕様では、認可サーバーはネイティブアプリをクライアント認証できない。そのため、認可サーバーは認可コードを横取りした不正アプリと正規アプリを識別できない。しかし、PKCEの仕組みにより認可サーバーは正規アプリを識別できるようになり、認可コード横取り攻撃の検知が可能となる。 ネイティブア
OAuth認証とは何か?なぜダメなのか - 2020冬 - r-weblife
こんばんは。ritouです。 Digital Identity技術勉強会 #iddance Advent Calendar 2020 1日めの記事です。 qiita.com 初日なのでゆるふわな話をしましょう。 何の話か もうだいぶ前ですね。9月のお話です。こんなTweetを見かけました。 社内Slackにいる「OAuth認証」と書くと訂正してくれるbotが丁寧な解説をするようになっていた 認証(Authentication)と認可(Authorization)は間違えやすいわりにミスると甚大な被害をもたらしがちなので、常日頃から意識を高めていきたいですね pic.twitter.com/oVQxBgZcHS— greenspa (@greenspa) 2020年9月28日 このbotに対する思うところはもう良いです。 今回は、「OAuthの仕様に沿ってID連携を実装するいわゆる"OAut
アプリで「ログインしっぱなし」はどのように実現されているか？ - Qiita
このツイートを見て、「アプリで再ログインを頻繁要求されるってユーザビリティ良くないな。」と思ったのですが、普段裏側の仕組みは意識していなかったりテックリードの方に任せきりだったりしていたので、これを機に調べてみました。 そもそもスマホアプリ の時代、もはやauthenticationですらないと思うのよね。（何を言ってるかわからねえだろうと思うが。） — Hiromitsu Takagi (@HiromitsuTakagi) 2019年7月8日 この記事は「アプリでログインしっぱなしは、どのように実現されるの？」という疑問と調べた結果を共有するために書いていきます。 間違いや「もっとこんな仕組みが使われてるよ！」等のツッコミがあれば、どしどし貰えると助かります！ 疑問1. アクセストークンという仕組みとは？ 「なぜアクセストークンという概念が必要なのか？」 モバイルアプリでユーザー認証をし
マイクロサービスでの認証認可 - Qiita
複数のクラウドサービスを利用している（マルチクラウド）など、単純には閉域網を構築できない環境でマイクロサービスアーキテクチャを採用する場合には、サービス間の認証認可が必要となる。この場合のサービス間の認証認可方式を決める参考となる、OSSやSaaS、Webサービスで採用方式ついて整理した。 Istio サービスメッシュの実装として有名なIstioではサービス間通信を以下のように制御できる。 Istioの認証認可では認証主体がService Identityというモデルで抽象化され、KubernatesやIstioで定義するService Accountに加えて、GCP/AWSのIAMアカウントやオンプレミスの既存IDなどをService Identityとして扱うことができる。 サービス間の認証 (Peer Authentication) は、各サービス (Pod) に設置するSideca
単なる OAuth 2.0 を認証に使うと、車が通れるほどのどでかいセキュリティー・ホールができる
In some of the feedback I have gotten on the openID Connect spec, the statement is made that Connect is too complicated. That OAuth 2.0 is all you need to do authentication. Many point to Identity Pro… 英語読みたくないという人のために簡単に解説すると… OAuth 2.0 の implicit flow を使って「認証」をしようとすると、とっても大きな穴が開きます。 カット＆ペーストアタックが可能だからです。 OAuth 認証？は、図１のような流れになります。 図１ OAuth 認証？の流れ 一見、問題なさそうに見えます。しかし、それはすべてのサイトが「良いサイト」ならばです。 Site_A
OAuth 2.0 の勉強のために認可サーバーを自作する - Qiita
逆に、RFC 6749 以外で定義されている認可フローをサポートする場合、新たに別のエンドポイントの実装が必要になることがあります。例えば CIBA（Client Initiated Backchannel Authentication）ではバックチャネル認証エンドポイント（backchannel authentication endpoint）、デバイスフロー（RFC 8628）ではデバイス認可エンドポイント（device authorization endpoint）の実装が求められます。 この記事では、認可エンドポイントとトークンエンドポイントを実装します。サポートする認可フローは認可コードフローのみ、サポートするクライアント・タイプはパブリックのみとします。 2. 注意点 下記の理由、および書かれていないその他の理由により、本実装は商用利用には適していません。 セキュリティー上必須
【書評】雰囲気でOAuth2.0を使っているエンジニアがOAuth2.0を整理して、手を動かしながら学べる本 #技術書典7 | DevelopersIO
【書評】雰囲気でOAuth2.0を使っているエンジニアがOAuth2.0を整理して、手を動かしながら学べる本 #技術書典7 技術書典7で頒布された「雰囲気でOAuth2.0を使っているエンジニアがOAuth2.0を整理して、手を動かしながら学べる本」を読んでみたのですが、良かったので紹介します。 以下で購入可能です。 雰囲気でOAuth2.0を使っているエンジニアがOAuth2.0を整理して、手を動かしながら学べる本 雰囲気でOAuth2.0を使っているエンジニアがOAuth2.0を整理して、手を動かしながら学べる本 すごくざっくり言えば、OAuth 2.0 ってなんなの？と、実際にサービスのエンドポイントを叩いて各フローを実際に体験するチュートリアルから構成されています。 私が特に良いなと思ったのは、 実際に存在するサービスを使った例に合わせて説明が進むので、それぞれのロールが「そもそも
「GoogleがGmailの内容を外部企業に読ませている」という記事について - @stomita daily (or monthly, yearly)
Forbes Japanに以下のような記事が掲載された。 forbesjapan.com これについて記事を読んだ人たちのTwitter等での反応を見ていたのだけれど、その反応にちょっと違和感を感じたので、今回少し書いている。 まず最初の反応として、NewsPicksでのコメントを見てみる。 newspicks.com 「メール内容を読ませていいと同意した覚えはない」というコメントが多く、そこから転じて「Gmailは守秘が必要な用途で使うべきでない」「無料のサービスを使うということはこういうことなんだ」のような意見も見られる。 一方、はてブでの反応は、流石に技術者が多いコミュニティということもあり、ちょっと調子は異なっている b.hatena.ne.jp 何事かと思ったらOAuthのことだったｗ - gogatsu26のコメント / はてなブックマーク OAuth2で同意とってるなら普通じ
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
Big Sky :: コマンドラインアプリで OAuth2 認証を使う際に使えるテクニック
OAuth2 でレスポンスタイプがコードもしくはトークンの場合、ブラウザで認証を行ってコードやトークンを自前サーバで受け取る事になる。モバイルアプリだと組み込みブラウザが前提になっておりリダイレクトの最終 URL からアクセスコードやトークンを得る。ただコマンドラインアプリの場合、認証の為に起動したブラウザの最終 URL を得る方法はない。また1コマンドラインアプリケーションの為にドメイン付きのコールバックサーバを用意するのも面倒だし、作ったサーバをユーザに信用して貰う必要がある。あとそもそも外部のサーバで受け取ったトークンをどうやってコマンドラインアプリに渡すかという問題がある。 そこで使うのがローカルサーバを立てる方法。認証後のコールバック先をコマンドラインアプリから起動したローカルサーバにし、そこにリダイレクトさせてアクセストークンを貰い保存する。 今日はこれが伝わり易い用に Mic
あなたにおすすめするWebSocketを用いた全く新しいOAuthのご紹介 - あざらし備忘録。
この記事は、 Advent Calendar 2016 - VOYAGE GROUP techlog の16日目のエントリです！ みなさんこんにちは！ VOYAGE MARKETINGにてエンジニアをしている なかにしごう (@gomachan46) | Twitter です。 2014年より社内非公式サークルとして 音ゲー部 を立ち上げ、お昼休みは会議室のプロジェクターで音ゲー鑑賞、定時後はゲームセンターで練習と、現在もなお元気に活動しています。 さて、今回はタイトルの通り WebSocketを用いた全く新しいOAuth をご紹介したいと思います。 ご存知の方も多いとは思いますが、さらっと簡単に用語の説明をしていこうと思います。 WebSocket WebSocket（ウェブソケット）は、コンピュータ・ネットワーク用の通信規格の1つである。インターネットの標準化団体であるW3CとIETF
マイクロサービスで必要になるかなぁって思って僕がOAuth2とOpenID Connectをなんとなく分かるようになるまでの物語 - Mitsuyuki.Shiiba
プライベートの勉強は気が向くままにふらふらと。梅田の地下街を歩いてる感じで！（←つまり迷ってる） 元々は、Pivotal Japanさんの、この「今日から君もヒーローだ！」的なタイトルに惹かれてJava(Spring Cloud)でマイクロサービス作るぞーって進めてみたのであった。が、早速その2の「認可サーバーを立ち上げよう！」で「あー、これ知らない。分かんない。もう寝たい。」となってしまったのだった。 そんな僕が「なんとなく分かった！」になるまでの物語。・・・になるはず（ここを書いてる今はまだ分かってない）。 たぶん1ヶ月したら何を読んだか忘れてると思うので記録しとくことにした。 github.com ゴール OAuth 2.0って聞いたことあるけど、よく知らない。この辺、マイクロサービスの認証・認可部分で必要そうだなーって思うので、OpenID 2.0とOpenID Connectも含
OAuth2 のフローを Alloy Analyzer でモデリングする - 詩と創作・思索のひろば
趣味でウェブの認証 API を地力で設計しようとしていたときに、認証フローの仕様を頑張ってこしらえたとして、その正しさをどうやって保証するんだろう？ と疑問に思い、調べていたところ、「形式手法」というのに行き当たった。 形式手法というのはシステムの正しさを上流工程から検証するための方法で、数理論理やロジックに基づいている。その中でも厳密な仕様定義を求める方向と自動検証を求める方向とあるらしいが、Alloy はその後者に位置づけられ、軽量形式手法と呼ばれるもののひとつだということらしい。Alloy はモデリングのための言語および実行環境で、以下のホームページから入手できる。 http://alloy.mit.edu/alloy/ インターネット上にチュートリアルやマニュアルもあるが、作者による教科書の邦訳が出ていて、これで勉強してみた。 抽象によるソフトウェア設計−Alloyではじめる形式手
nginx-omniauth-adapterのGolangポート作った
「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
OAuthがソーシャルログインで使われるようになった経緯
最近の僕の趣味は、stack overflowに来た質問に回答を付ける、ということです。特に本家英語版の方では、英語の読み取りと作文の練習をかねてやってます。もちろん、日本語版の方でも、回答できそうな質問が来たら、積極的に回答するようにしています。たまに間違えた回答付けてしまって-1をもらうこともありますが、それを含めての貢献かな、と。気にしない気にしない。 さて、日本語版の方でOAuthに関する以下の質問が来ていました。 OAuthはどのようにしてソーシャルログインとして使用されるようになったのでしょうか？ 下記の記事をみるとOAuthはもともと外部からAPIを呼ぶためのものであり、ソーシャルログインとして使うのはHack的な使い方のような印象をうけました。 本来の目的が、ソーシャルログインのためでないならどのような経緯(どこどこのサービスで使われたのがきっかけというような歴史）でソーシ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
