今朝こちらの Tweet みて気がついたんですが、Google が OpenID 2.0 のサポートを2015年4月20日で終了するようです。 Developers beware! Google has published its timeline for deprecation of OpenID 2.0:http://t.co/84cIS0wR1D — Gluu (@GluuFederation) January 7, 2015 本当にそんな短期間で OpenID 2.0 止めて大丈夫なのかって気がしますが、Google OpenID 2.0 Shutdown Timetable によると、4/20で全てが止まるようです。 僕が把握しているところでは、以下のサイトは現時点でまだ Google OpenID 2.0 を使っています。他にもいっぱいあるんでしょうが、僕は把握してません。他に
昨日あたりから、Yahoo! Wallet や YConnect といった、Yahoo! Japan の API にアクセスできなくなったって人、ちらほらいるかもしれませんね。 僕もちょっとそういうケース見かけました。 なんか Yahoo! Japan がポカしちゃったの?とか、まぁ昨日まで健康に動いてたシステムが突然 Yahoo! Japan の API にアクセスできなくなっちゃったんだし、そらそう思うのもムリはない。 が、今回のケース、Yahoo! は全く悪くない! プライバシーフリークはどうかと思うがな!! では早速、今回起こったことを、振り返ってみましょう。 Yahoo! API にアクセスできなくなった Yahoo! Japan は、yahoo.co.jp 以外にも、CDN 用や API 用など、用途ごとにいくつかのドメインを持ってます。 今回止まったのは、その中の API 用
先日 JWT & JWS 翻訳プロジェクトスタート & イベント紹介 でお伝えした JWT & JWS 翻訳プロジェクトですが、無事翻訳をリリースできました。 JSON Web Token (JWT) JSON Web Signature (JWS) JOSE UseCases OpenID TechNight Vol.10 ではこれらの仕様の概要説明も行いましたので、そこでのスライドもここに挙げておきます。 (なぜかいま現在僕の環境ではこちら404 Not Foundになってしまいますが…) JWT & JOSE 翻訳 引き続き JSON Web Encryption (JWE) および OAuth2 JWT Bearer Token Profile も翻訳予定です。(スケジュール未定) 翻訳にご協力いただける方は、@nov まで :)
ずいぶん前に「OAuth 2.0 Core & Bearer Spec 翻訳公開!」で紹介したように、OAuth 2.0 Core & Bearerは、OpenID Foundation Japanの翻訳WGで翻訳を公開していましたが、2012年に両specがRFC化されたのを受け、今回RFC版も翻訳しました。 The OAuth 2.0 Authorization Framework (RFC 6749) The OAuth 2.0 Authorization Framework: Bearer Token Usage (RFC 6750) 前回翻訳したdraft版から仕様自体に大きな変更はありませんが、特に まだdraft版も読んだことが無い人 自社のAPIドキュメントからdraft版の翻訳にリンクしている人 などは、RFC版を参照していただければと思います。 いまこれらとは別に、"O
2011年12月のOpenID Summit Tokyoで、2012年中のOpenID Connect対応を宣言したYahoo! Japanが、本日ついに宣言通りOpenID Connectをサポート開始しました。 もともとOAuth 2.0も対応していなかった(よね?)ので、OAuth 2.0対応も同時リリースです。 まだバグとかあるっぽいけど、何はともあれ世界の大手IdPの中で一番最初にproduction環境でOpenID Connect対応できたのはすばらしい! OpenID Summit Tokyo 2011 from Taizo Matsuoka まだOpenID ConnectのDiscoveryとDynamic Registrationには対応していないので、Nov RPに "yahoo.co.jp" とか入力しても使えない状態ですが、それは今後に期待です。 YConnec
おひさしぶりです、@novです。 最近は、新しいFacebook iOS SDK使ってるアプリを見つけるとまずToken置換攻撃を試みていますが、結構高い確率でこの攻撃に対して脆弱なアプリがみつかります。困ったものです。。 そんななか、2週間ほど前に、Micosoft Researchの人がIETF OAuth WGのメーリングリストに同じ問題を提起していました。該当Threadでは少し話題が脱線している部分もありますが、もともと最初にこの問題を提起したJohn BradleyがOAuth 2.0 CoreにSecurity Considerationsを追加する流れのようです。 これが現状の改善につながれば良いのですが、そう簡単に行かないかもなとも思います。というのも、この問題、なかなかデベロッパーにとって理解されない傾向があります。 そこで今日は、これまでいくつかのアプリデベロッパーに
いままで Mix-up Attack は Client が AS 毎に redirect_uri を使い分けていれば防げると信じられてきましたが、それじゃ防げないケースもあるよってのが OAuth ML に投稿されました。 細かい解説は英語読んでもらうとして、シーケンスにするとこういうことです。 Attacker AS が (Display Name やロゴ等を通じて) 一見 Honest Client に見えるような Client (Attacker Client) を Honest AS に登録しておく必要があります。 User が Attacker AS 選んでるのに Honest AS に飛んで Approve してしまってる部分も、Attacker Proxy が利用可能な状況 (e.g., Client が HTTP なエンドポイントで Honest AS のログインボタン等を
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く