OpenID Connect 全フロー解説 - Qiita
はじめに OpenID Connect は OAuth 2.0 を拡張する形で策定されました。 OAuth 2.0 はアクセストークン発行手順に関する仕様で、RFC 6749（The OAuth 2.0 Authorization Framework）で定義されています（参考：一番分かりやすい OAuth の説明）。 一方、OpenID Connect は ID トークン発行手順に関する仕様で、主要部分は OpenID Connect Core 1.0 で定義されています（参考：一番分かりやすい OpenID Connect の説明）。 RFC 6749 は認可エンドポイントという Web API を定義しています。 この API は必須のリクエストパラメーターとして response_type を要求します。 OpenID Connect は、この response_type の仕様を拡
OAuth 2.0 の脆弱性 (!?) "Covert Redirect" とは - OAuth.jp
訂正 リダイレクト時の fragment の扱いを勘違いしていたため、本記事全体訂正します。 細かく訂正いれてると分けわかんなくなってきたんで、新しい記事書きました。 ゴールデンウィークまっただなかに Twitter で海外の ID 厨から袋だたきにあってたので、もうこの問題は片付いただろうとすっかり油断してた「Covert Redirect」の件ですが、日本でもゴールデンウィーク明けてバズりだしたので、一旦問題を整理した方がよさそうですね。 事の発端 Wang Jing さんていうシンガポールの大学院生が、こんなサイトを公開すると共に CNet はじめ各種メディアが取り上げたのが、バズりだした発端のようです。 前提知識 OAuth 2.0 や OpenID Connect だけでなく、OAuth 1.0 や OpenID 1.0/2.0 や SAML なんかでも、2つのサービスの間でリダ
事務局ブログ：「Covert Redirect」についての John Bradley 氏の解説（追記あり）
追記 (5/7 20:30): 本文中に「まともなブラウザーであれば、そのフラグメントを URI の一部にするようなことはないから、オープン・リダイレクターには送られない。」とありますが、少なくとも Chrome と Firefox はリダイレクト時に URI フラグメントをそのまま保つ (i.e. 不十分な redirect_uri チェック & オープン・リダイレクター & インプリシット・フローの場合、アクセス・トークン入りの URI フラグメントを、ブラウザーがそのままリダイレクト先へのリクエストに用いる) とのことです。続報があり次第追記します。 追記2 (5/7 23:50): John Bradley 氏自身によるフォローアップを訳しました。 Covert Redirect and its real impact on OAuth and OpenID Connect を、と
OpenID 2.0の一部実装に脆弱性、その詳細と対策とは
OpenID 2.0の一部実装に脆弱性、その詳細と対策とは：デジタル・アイデンティティ技術最新動向 臨時便 米OpenID Foundationが8月15日に、OpenID 2.0の一部OpenID Provider（OP）実装において、Relying Party（RP）上でのアカウントハイジャックにつながる可能性のある重大な脆弱性が見つかったことをアナウンスしました。この記事では、その詳細と対策について述べます。 8月15日に公表されたアカウントハイジャックの脆弱性 OpenID Foundation Japan、Evangelistの@novです。 2013年8月15日に米OpenID Foundationからリリースがあったように、OpenID 2.0の一部OpenID Provider（OP）実装に、Relying Party（RP）上でのアカウントハイジャックにつながる可能性のあ
アイデンティティ管理技術解説：IPA 独立行政法人 情報処理推進機構
背景と目的 今日のアイデンティティ管理技術は、人々に付す識別子（ID）のみを扱う技術ではなく、多様な属性情報を管理するものとなっています。属性情報をオンラインで利用する際にも複数の目的があり、人々を本人であると認証すること、人々の属性情報を交換することの他、人々の属性情報に基づいてアクセスを制御すること等が挙げられます。そして、それぞれの目的に利用できる技術仕様が複数、策定されています。 このようにアイデンティティ管理技術は多種多様性を増しています。 しかし、アイデンティティ管理技術を全体観をもって解説する取り組みがなされてこなかったので、情報処理技術者が体系的に把握して学習することが容易ではない状況にあります。今日、多種のアイデンティティ管理技術の中から自らのシステム構築に適するものを選択したり、他者が採用しているアイデンティティ管理技術との間で相互運用可能性を確保することを検討したりす
Federation Lab
Welcome to Federation Lab. Here you should be able to perform automated testing of software supporting SAML, OpenID Connect, OAuth and more. OpenID Connect Test Lab This beta edition includes support for automated testing of an OpenID Connect Provider. If you have comments or questions about this tool, contact Andreas Åkre Solberg and Roland Hedberg. Test an OpenID Connect Provider GÉANT, NorduNet
OpenID SAMLとの違い
OpenIDとSAMLとの違いについてまとめる。 【参照URL】 http://identitymeme.org/doc/draft-hodges-saml-openid-compare.html 上記の資料に丁寧にまとめられているが、今理解している範囲でまとめると、ポイントは以下になる。 SAML仕様は、運用前に、信頼関係（トラストサークル）を構築する必要がある（SPとIdP間でのメタデータの交換、証明書の交換）。OpenID仕様では、信頼関係を構築する必要がない。どのRPもOPと認証連携できることが原則。なお、OpenID仕様では、OpenIDのプロトコルの中で、OPのエンドポイントURLのディスカバリ、共有鍵の交換を実施している。 1により、PKI基盤を用いているSAML仕様のほうが、セキュリティ強度が高いと思われる。 SAML仕様では、アサーションという認証情報（XML形式）を規定
押さえておきたいOpenIDとSAML３つの大きな違い : やむにやまれず
2007年09月19日17:41 by 山崎泰宏 押さえておきたいOpenIDとSAML３つの大きな違い カテゴリネタ Tweet sparklegate Comment(5) 技術的にどうかという話はあちこちに書かれているので割愛しますが、これらのクロスドメイン認証はどんなものなのかをもう少しザックリとまとめてみました。 もっと良いまとめができるかも知れないけど、現在勉強中なのでひとまずこのレベルで。 何か思いついた方はぜひコメントなりトラックバックなりください。 以下は、OpenID 1.1と、SAML 2.0を前提に書きます。 1. ユーザが利用する認証システムを静的に固定しているのがSAML/動的に決定できるのがOpenID システム間で事前に準備するものに注目してみましょう。 SAMLでは認証のサービスを開始する前に、相互のシステムへメタデータと言う連携先の情報を記録したプロパテ
情報セキュリティ技術動向調査（2011 年下期）：IPA 独立行政法人 情報処理推進機構
OpenID 2.0 は実装を容易にするために、ユースケースを「OpenIDプロバイダのID情報を用いた、RPへのログイン／属性提供」に限定した仕様となっている。その結果、以下のような要件を満たすことは、仕様の範囲内では容易ではない（図2）。 機能の制限された Web ブラウザへの対応 OpenID 2.0 では、ユーザ・エージェントとして一般的なWebブラウザを対象としており、ある程度大きなURL長を処理する能力や、リダイレクト機能などを有する必要がある。そのため、携帯端末などのように機能が制限された環境のWebブラウザでは、OpenID 2.0 プロトコルを処理できない場合がある。 セキュリティ要件への対応 OpenID 2.0 プロトコルでは、Web サイト間でのID情報の要求（認証リクエスト）ならびにその提供（アサーション）は、Webブラウザのリダイレクト機能を用いて、平文のメッセ
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
OAuth 2.0やOpenIDの最新動向に追いつくために勉強したことまとめ。 - hsksnote
OAuthやOpenID、仕組みもよく知らずに使ってきた僕が、その最新動向に追いつくために勉強したことをまとめます。 きっかけは OpenID TechNight #7 をUstで見たことで、わからないことが山盛りだったので色々と調べてみた。 OpenID TechNight #7 : ATND 各発表のスライドへのリンクがあるよ。 キーワードとしては、OAuth 2.0、OpenID Connect、Cloud Identity、RESTful API、といったあたりについて。それぞれ基本的なことと、Ustで話されてたことをまとめる。 OAuth 2.0 OAuth 2.0でWebサービスの利用方法はどう変わるか（1/3）- ＠IT を先に読めばよかった。 簡単にまとめると、OAuth 1.0の問題点は3つあって。 認証と署名のプロセスが複雑 Webアプリケーション以外の利用が考慮されて
OpenID Provider のセキュリティ対策 (1) - まずは SSL を導入！話はそれからだ - 日向夏特殊応援部隊
やっと下準備終わったので書いてみる。 OpenID でのプトロコルメッセージで、認証アサーション要求*1及び応答*2でのメッセージは通常、RP-OP 間で associate 時に交換した MAC キーを持って署名を行う為、期待する相手と通信している限りは改ざんは起こりにくいと考えられます。 但し最近話題に出て来ている DNS Cache Poisoning のような攻撃を受けた場合、中間者攻撃 (man-in-the-middle attack) が成立する可能性があります。 攻撃手法の例 例えば、RP の DNS が汚染されていた場合を考えます。本来 OP であるはずのホストが悪意のある第三者のサーバーに割り当てられていた場合、その第三者のサーバーが中継を行えば、DH 鍵交換を行ってもまったく無意味で、認証データが盗まれる可能性があります。つまり、 RP から見ると OP に見えて O
OpenID ファウンデーション・ジャパン - Event Report 【OpenID Tech Night Vol.6】
OpenIDファウンデーション・ジャパン（OIDF-J）主催の技術セミナー第6弾「OpenID Tech Night Vol.6」が、2010年5月28日、株式会社野村総合研究所より会場のご提供をいただき開催されました。 ◆はじめに◆ 勝原 達也（株式会社野村総合研究所） IdentityやWeb Identity Technology、OpenIDとOAuthの歴史、認可と認証についてご紹介頂きました。 ※講演資料：http://www.slideshare.net/kthrtty/open-id-technightvol6kthrttyslidesharever ◆OpenIDセッション◆ 真武 信和（セレゴ・ジャパン株式会社） OIDF-J翻訳・教育WGリーダーより、今回のイベント告知にも使われた「ATND」を例にOpenID及び拡張仕様をご紹介いただきました。 ※講演
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PDSを実現するにあたっての技術動向の紹介 (OAuth, OpenID Connect, UMAなど)