OpenID Foundation Japan
公開資料 OpenIDファウンデーション・ジャパンでは、OpenID関連技術仕様の日本語訳や、プレゼンテーション資料、その他各種文書を公開しています。 技術仕様 OpenID Connect OpenID Connectは、OAuth 2.0をベースとする、シンプルなアイデンティティ連携プロトコルです。 ここでは日本語訳された仕様を紹介しています。原文ならびにその他の仕様については http://openid.net/connect/ をご参照ください。 OpenID Connect 1.0 specification OpenID Connect Core 1.0 日本語訳 OpenID Connect 1.0 は, OAuth 2.0 プロトコルの上にシンプルなアイデンティティレイヤーを付与したものである. このプロトコルは Client が Authorization Server
OpenID Connect についてと OAuth2.0 との違いを調べてみた
※この記事は別アカウント(hyiromori)から引っ越しました はじめに 最近、個人的に認証認可周りを学習していて、今回は OpenID Connect について学習したのでその内容をまとめた記事です。 世の中には既に OpenID Connect に関する優れた書籍やブログ記事が沢山ありますが、自分が学習する過程で色々なものを読むことでより理解が深まったと思うので、自分も学習したものをアウトプットすることで同じように学習している人の理解の助けになればと思い書きました。 まだ私も学習中なので、もし間違ったところなどあればコメント頂けるとありがたいです。 OpenID Connect とはなにか？ OAuth2.0をベースにして（認可だけでなく）認証も行えるようにした拡張仕様です。 なぜOAuth2.0が認証に使えないかというと、以下のように認証に使ってしまうとリスクが非常に高いからです。
OpenID Connect、OAuth、SAMLの違いと用途とは？ | Okta
サイバー攻撃のパターンが多様化、高度化してきているように、防御の手法も数多くあります。従来の境界防御、ゼロトラストセキュリティアーキテクチャの採用、アイデンティティを守る手法においても、多要素認証、シングルサインオン、フィッシング対策など、検討項目は多岐にわたります。そして、開発者やIT担当者にとって、データとアイデンティティを如何に安全に保つかという選択は、フェデレーションアイデンティティを安全に保つために導入すべき標準を選択することから始まります。 この判断は必ずしも一筋縄ではいきません。OAuth 2.0、OpenID Connect、SAML（Security Assertion Markup Language）は、それぞれがフェデレーションプロセスの構造を形成するものですが、違いを理解しにくい人が多いようです。ここでは、これらの標準の意味、比較、使用目的の違いを明確に解説いたしま
OAuth 2.0/OIDCに入門した開発者が仕様沼に潜るための次のステップとは？ - r-weblife
お疲れ様です、ritou です。 OAuth 2.0やOIDCの入門書(?)を読み終えた開発者の方に、仕様を理解していくための次のステップは何があるかを聞かれました。 そもそもそんなこと言う人は クライアントを実装したい(しなければならない) 認可サーバーを実装したい(しなければならない) セキュリティエンジニアを名乗っていてこの分野を抑えときたい ただ単純に興味がある : そんな人いる？ とかそんな感じな気はしますが、基本的なフローを乗り越えた先に広がる仕様沼への潜り方に戸惑っておられるようでした。 そこで、いわゆる RFC6749/6750/7636 あたりを完全に理解した開発者が山ほどある仕様にどう立ち向かっていくかを考えます。 仕様にも色々ある IETF の OAuth関連の仕様、いっぱいあります。密です。密です。みみみみみみみみ... tools.ietf.org 去年に一回まと
マイクロサービスで必要になるかなぁって思って僕がOAuth2とOpenID Connectをなんとなく分かるようになるまでの物語 - Mitsuyuki.Shiiba
プライベートの勉強は気が向くままにふらふらと。梅田の地下街を歩いてる感じで！（←つまり迷ってる） 元々は、Pivotal Japanさんの、この「今日から君もヒーローだ！」的なタイトルに惹かれてJava(Spring Cloud)でマイクロサービス作るぞーって進めてみたのであった。が、早速その2の「認可サーバーを立ち上げよう！」で「あー、これ知らない。分かんない。もう寝たい。」となってしまったのだった。 そんな僕が「なんとなく分かった！」になるまでの物語。・・・になるはず（ここを書いてる今はまだ分かってない）。 たぶん1ヶ月したら何を読んだか忘れてると思うので記録しとくことにした。 github.com ゴール OAuth 2.0って聞いたことあるけど、よく知らない。この辺、マイクロサービスの認証・認可部分で必要そうだなーって思うので、OpenID 2.0とOpenID Connectも含
Authorizing a request | Twitter Developers
Overview The purpose of this document is to show you how to modify HTTP requests for the purpose of sending authorized requests to the Twitter API. All of Twitter's APIs are based on the HTTP protocol. This means that any software you write which uses Twitter's APIs sends a series of structured messages to Twitter's servers. For example, a request to post the text "Hello Ladies + Gentlemen, a sign
Twitter Login にも CSRF 脆弱性ができやすい罠が!? - OAuth.jp
OAuth 2.0 では state パラメータってのがあって、それをちゃんと使わないと CSRF 脆弱性ができちゃうよって話は、@ritou 先生のスライドなどでみなさん勉強したんではないでしょうか。state パラメータは RFC 6749 では RECOMMENDED 扱いで、REQUIRED ではありませんが、OAuth 2.0 をログインに使う場合は REQUIRED にすべきでしょう。OAuth 2.0 をログインに使うの、Token 置換攻撃とか Covert Redirect + Code 置換攻撃とか、いろんな罠がありますねぇ〜。 OAuth 1.0 ならそんなことないのに… そう思ってた時期が、僕にもありました。 でも @ritou 先生よく言ってるじゃないですか。「Twitter の OAuth 実装クソや」って。でね、ほんとにクソやったんすよ、コレが。 さて、Dev
事務局ブログ：「Covert Redirect」についての John Bradley 氏の解説 - 訂正版
先ほどの翻訳記事の原文への @miyagawa 氏からの指摘を受けて John Bradley 氏が新たな記事「OAuth 2 and Fragment encoding.」を書かれているので、翻訳します。 おぅ、わいや、John や。 昨日はカリフォルニアで開催されてるID厨の祭典「Internet Identity Workshop」ちぅイベントで、IETF OAuth WG のメンバーが Open Redirector の問題について話し合ったで。 数年前 JavaScript クライアントを想定してレスポンスの fragment encoding を採用する際、わいらはその選択についてそらぁ連日朝まで語り合ったもんや。 レスポンスの fragment encoding を採用した理由はいくつかある: JavaScript クライアントが token を取得するために、一度 serv
Implicit Flow では Covert Redirect で Token 漏れるね - OAuth.jp
この記事は、先ほど書いたこちらの記事の訂正版です。 記事に入る前に、まずは全シンガポールにお詫び申し上げますm m さて、Covert Redirect についての説明は…超絶取り消し線はいりまくってる前の記事を読んでください、でいいでしょうか？ で、訂正分だけ以下に。 Fragment Handling in Redirect 宮川さんが記事にしてますね。 英語だけど。 で、まぁ要するに、(Modern Browser は) 30x リダイレクト時にリダイレクト元に付いてた URL fragment をリダイレクト先にも引っ付ける、と。 fragment は server-side には送られないけど、クライアントサイドではリダイレクト先に引き継がれる、と。 試しに http://www.idcon.org/#foobar にアクセスすると、http://idcon.org/#fooba
Covert Redirect Vulnerability with OAuth 2
tl;dr Covert Redirect Vulnerability is a real, if not new, threat when combined with Implicit Grant Flow (not Code flow) This Covert Redirect Vulnerability in OAuth 2 is an interesting one. There’s a couple of defending arguments that this isn’t a flaw in OAuth itself. While I agree that it isn’t a flaw in the protocol, I think the threat is a real one, combined with a) a loose validation on redir
特定条件下におけるOAuth 2.0の認可応答を奪取されるリスクとその対策について - r-weblife
こんにちは、ritouです。 やっと”なんちゃらAdvent Calendar”がおさまり、これからは”一年を振り返って(遠い目”みたいな記事が増えることでしょう。その間のタイミングを狙います。 何の話か mixi Platformが導入したっていうOAuth 2.0のCSRF対策拡張を使ってみた - r-weblife の最後にちょっと書いたんですけど、モバイルアプリでOAuth 2.0を使う際にやっかいな問題が残ってました。 今回は、「ネイティブアプリケーションからOAuth 2.0を使うとき、特定の条件下において、正規のClientではない悪意のある第3者に認可応答を持って行かれて、その結果Access Tokenを取得できちゃうリスクがあるよね。どうしようか。」っていう話です。 条件っていうのは、 OAuth 2.0のClientはネイティブアプリケーションであり、Client C
Python Social Auth
Python Social Auth is an easy to setup social authentication/registration mechanism with support for several frameworks and auth providers. Crafted using base code from django-social-auth, implements a common interface to define new authentication providers from third parties. And to bring support for more frameworks and ORMs. Learn more » Frameworks The lib supports a few frameworks at the moment
Gmail のメールを OAuth で読む (Perl) | tech - 氾濫原
Gmail のメールを OAuth 経由で読むことができることを今更ながら知った。なぜかずっと「Gmail はユーザ名・パスワード認証しかできなくて不便だな〜 パスワード書きたくないな〜 OAuth できたらな〜」と OAuth ができないものだと思いこんでいた。 で、簡単に読めるモジュールがあるかなあと思ったけど、ちょっと見た感じではないので自力で書いてみた。 https://gist.github.com/cho45/5814655 Gmail + OAuth の基礎知識 概要としては OAuth のアクセストークンを得る メールアドレス (アカウント名) + アクセストークンを使って SASL XOAUTH2 フォーマットの文字列を作る IMAP を使い、AUTHENTICATE コマンドで上記文字列を送って認証する という感じで、OAuth は使うけれど、WebAPI で Gmai
Tav's Blog » OAuth 3.0: The Sane and Simple Way To Do It
I'm a big fan of OAuth and I've done my fair share of promoting it — from writing various open source client libraries to implementing services using it. However, the OAuth 2.0 spec is a bit of a mess. It's overly prescriptive and, given that there isn't a single conformant implementation by a major service provider, perhaps too complex for even the big boys. Take Facebook. They boldly claim OAuth
RESTを自称してはいけない
APIを自らRESTfulだと称してはいけない – このアドバイスは，Nodeup podcast - an APIs showの先日のエピソードで，API開発者たちが語った中のひとつだ。そのポッドキャストでは，Nodeupのホストを務めるVoxerの技術者Daniel Shaw氏，Browserlingの創立者James Halliday氏，そしてゲストのMark Cavage氏とAndrew Sliwinksi氏を交えた会話を繰り広げている。Cavage氏はクラウドインフラストラクチャのプロバイダ Joyentのソフトウェア技術者で，Node.jsのパッケージRestifyの作者でもある。JoyentはNode.jsを所有すると同時に，広範囲に活用している企業だ。もうひとりのSliwinski氏は，子供向け体験Webサイト DIY の共同創設者で，CTOを務める人物だ。 API設計の話
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - blebbit/authr: Our Authnz Services
🚧 OAuth2 - Authorization Server by matthieusieben · Pull Request #1958 · bluesky-social/atproto
👹秋田の猫🐱 (@ritou.bsky.social)
OAuth/OpenID Connectを用いてID連携を実装するときに気を付けること #yapcasia
GitHub - joestump/python-oauth2: A fully tested, abstract interface to creating OAuth clients and servers.
