Sign in with Apple の特徴分析 (1) - OAuth.jp
前記事 で書いたように、ここ数日 Sign in with Apple 用の RubyGem 作りながら、Sign in with Apple の特徴というか、他の IdP との違いみたいなところいろいろ調査したので、現時点での Sign in with Apple に対する雑感をまとめておきます。 Client ID と Team ID および App ID との関係 個人として Apple Developer Account 使ったことしかないんで、会社として Developer 登録してる時の Team の扱いとかよくわかってないんですが、Apple Developer Account 登録すると Team ID ってのが割り振られます。個人だと 1 Developer Account に 1 Team ID。 この1つの Team ID の下に、複数の子 App ID が登録可能で
LINE ID Login - OAuth.jp
LINE が OpenID Connect サポートしたみたいですね。 なんか前からしてんだと思ってたんですが、まぁいいや。 ということで、早速触ってみました。 こちらに今回使った Ruby のサンプルスクリプト置いておきます。 まぁ、ちょっと特殊な点がいくつかありますが、十分 OpenID Connect です。 気になった点は以下の通り。 ID Token の署名アルゴリズムが HS256 (HMAC-SHA256) HMAC ってことは、署名検証するために client_secret が必要ということです。 Native App で検証しようとすると、Native App に client_secret を埋め込まなければならない訳ですが、それはありえないので、要するに Native App で ID Token の署名検証はできないということです。 まぁ別に Native App
GitHub Business Plan 登場、GitHub.com ドメインで SCIM と SAML をサポート。 - OAuth.jp
オンプレサーバーで GitHub Enterprise をお使いのみなさま。 日々オンプレサーバーのメンテ、おつかれさまです。 GitHub.com の Business Plan っての、良さそうですよね。 SCIM と SAML サポートしてて、いままでオンプレ版でしかできなかった Provisioning と Federation (SSO といった方が伝わるか？) が、GitHub.com ドメインでできるようになったんですよ。 これで GitHub.com が生きてればいつでも Deploy できますよ。 死ぬもんね、オンプレ。てか、一旦死んだら結構しばらくの間死ぬもんね、オンプレ。 GitHub.com なら、AWS が生き返ればきっと生き返るよ。 ということで、Business Plan の SAML と SCIM、ちょっと試してみましたよ。 SAML 設定 GitHub H
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 /
OAuth / Connect における CSRF Attack の新パターン - OAuth.jp
昨日こんなのが OAuth ML に流れてました。 [OAUTH-WG] Another CSRF attack 前提条件 RP (Relying Party a.k.a. OAuth Client) が2つ以上の IdP (Identity Provider a.k.a. OAuth Server) と連携している状況で、片方の IdP に悪意がある。 悪意ある IdP = AIdP (A は Attacker の略) その他の IdP = HIdP (H は Honest の略) 攻撃フロー Victim が AIdP を使って RP へのログインを試みる。 RP は Authorization Request を AIdP に送る。 AuthZ Req には Browser Session と紐付いた state パラメータをつけている。 AIdP は Victim を認証し、必要に
JWS 実装時に作りがちな脆弱性パターン - OAuth.jp
JOSE (Javascript Object Signing and Encryption) 愛で満ち溢れる ID 厨界隈において、燦々と輝く JWS (JSON Web Signature)、美しいですよね！ JWT がジャニーズなら、JWE は EXILE、JWS は石原さとみと言ったところでしょうか？ と、冗談はさておき、JWT をお使いの皆さんは、当然署名付けてますよね？署名検証しますよね？ そんなあなたに一言いいたい！ まだ HMAC で消耗してるの？ いや、決して HMAC オワコンとかは言ってないですよ？スマホアプリでの署名検証のために、アプリに共通鍵埋め込むのはナンセンスってだけで。 ということで、今日は JWS をお使いのみなさんに、実装時に作りがちな脆弱性パターンを2つご紹介します。 今日紹介する脆弱性の2つのうち、1つめは HMAC, RSA, ECDSA のどれを
IETF JOSE WG と OAuth WG から一気に9本の RFC が！ - OAuth.jp
一気に出ましたね。すでに過去にもいくつかは紹介したり翻訳したりしていますが、それぞれを簡単に紹介しておきます。 RFC 7515 – JSON Web Signature (JWS) RFC 7516 – JSON Web Encryption (JWE) RFC 7517 – JSON Web Key (JWK) RFC 7518 – JSON Web Algorithms (JWA) RFC 7520 – Examples of Protecting Content Using JSON Object Signing and Encryption (JOSE) JWS は署名付きのデータを JSON (の Base64 URL Encode) 形式で表現するための仕様で、多くの場合は JSON Payload に対して署名するケースで利用されます。JSON じゃないデータに対して署名し
Google OpenID 2.0 のサポート終了、OpenID Connect への移行はお早めに - OAuth.jp
今朝こちらの 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 を使っています。他にもいっぱいあるんでしょうが、僕は把握してません。他に
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
OAuth.jp
いままで 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 のログインボタン等を
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Azure Portal 上の PowerShell から O365 SAML 設定 - OAuth.jp
独立 & YAuth.jp 設立 - OAuth.jp