OAuth2 in Action が Amazon にも

Published on:
Tags:

我らが Justin Richer がずっと執筆進めてた OAuth2 in Action が Amazon.co.jp に登場してました。

目次はこんな感じ。

  • Part 1 – First steps
    • What is OAuth 2.0 and why should you care?
    • The OAuth dance
  • Part 2 – Building an OAuth 2 environment
    • Building a simple OAuth client
    • Building a simple OAuth protected resource
    • Building a simple OAuth authorization server
    • OAuth 2.0 in the real world
  • Part 3 – OAuth 2 implementation and vulnerabilities
    • Common client vulnerabilities
    • Common protected resources vulnerabilities
    • Common authorization server vulnerabilities
    • Common OAuth token vulnerabilities
  • Part 4 – Taking OAuth further
    • OAuth tokens
    • Dynamic client registration
    • User authentication with OAuth 2.0
    • Protocols and profiles using OAuth 2.0
    • Beyond bearer tokens
    • Summary and conclusions
Read on →

Azure AD B2C が外部 API 向けに払い出す JWT-formatted Access Token について

Published on:
Tags:

Azure AD B2C Access Tokens now in public preview

ということで、さわって見ました。

Step.1 Azure AD B2C テナントの作成

まずは Azure AD B2C テナントを作成します。なんか portal.azure.com から行くと Classic Portal ベースのドキュメントに飛ばされるので、新しい方の Portal ベースのドキュメントをリンクしときますね。

Azure Active Directory B2C: Create an Azure AD B2C tenant

テナントを Subscription と紐づけるとかいう処理は Production Use でない限り Skip で OK です。

Step.2 Web API (Resource Server) および Client の登録

Azure AD B2C Access Tokens now in public preview にしたがって、Web API と Client を登録します。

Web API の登録には Scope の定義もセットです。

Client の登録には Key (Client Secret) の作成と利用可能な API & Scope の設定がセットです。

ちなみに、Resource Server と Client がどちらも同じメニューから作成し、横並びで表示されるのはちょっと違和感ありますね。

Resource Server に Redirect URI (Reply URL) の登録が必須だったり、Implicit を使えるようにするかの選択は Client 側の設定項目で Resource Server 側にそれ設定してもなんの意味もなかったりというのは、MS さんらしいというかなんというか。

なお、

  • App ID URI を登録した Application は固有の scope を定義できるようになり、Resource Server になれる。
  • App ID URI を登録しない Application は Key (Client Secret) しか作成できず、Client にしかなれない。
  • Resource Server は Key (Client Secret) も作成できるので同時に Client にもなれる。

というルールになっているようですが、3つめの Resource Server かつ Client というのは同じ aud を持つ Access Token と ID Token が生成されることに繋がるので、よほどの事情がない限りやめるべきです。

Read on →

GitHub Business Plan 登場、GitHub.com ドメインで SCIM と SAML をサポート。

Published on:
Tags:

オンプレサーバーで 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 Help の この一連のドキュメント を読む限り、SAML 設定しないと SCIM 使えないようです。

あ、SAML の SP Entity ID とかはドキュメントには書いてないです。

Business Plan 契約して設定画面行かないと、SP Entity ID も Assertion Consumer Service (ACS) URL もわかんないです。

まず金払ってからしか試せません。

ファーストひどい。

Read on →

MacOS Sierra (10.12.x) でマイナポータルにログイン

Published on:
Tags:

お久しぶりです、nov です。

おかげで無事12月末で YAuth.jp も初年度を終え、2期目に突入しております。

MVP は意気込み送ってこいや的なメールが来ており、いいかげんそろそろ Windows 10 でドメインジョイン (正直 UX とかよくわかってない) せんとなぁとか思いつつ、今日は MacOS です。

MacOS でマイナポータルにログインするお話です。

みなさん、知ってましたか?マイナポータルって OpenID Connect の IdP なんですよ!もしかしたら Access Token とか払い出しちゃう機能なんかもあるんですよ!

ということで、まぁその辺を調べるにも、ログインせんことには何も始まりません。

え?マイナンバーカード持ってないだって??んなやつぁしらん!!!

そんな人は NIST SP 800-63-3 翻訳版 でも読んで、Identity Proofing とかハードウェアトークンとかに思いをはせつつ市役所いって取って来てください。

マイナンバーカード取る時、NIST SP 800-63-3 の3ページ目テストに出ますからね。

Read on →

HTTPS でも Full URL が漏れる?OAuth の Code も漏れるんじゃね??

Published on:
Tags:

なんですかこれは!

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 / OpenID Connect の Authorization Request & Response は GET です。

Implicit Flow の場合は Response Parameter が URL Fragment についてるので、Server に送られる Full URL が漏れたところで特に URL Fragment の内容は漏れないですが、Code Flow の場合は Response の Query についてる Authorization Code は漏れますね。

まぁ Authorization Request に含まれる state とかも漏れますが、今回のケースだと Cookie とかは漏れないんで、state が漏れること自体は大して問題ではないでしょう。

ただ、Redirect URL に HTTPS 使っても code 漏れるってのは、辛そうですね。

Authorization Code が漏れたらどうなるの?

Code 置換攻撃 (Code Cut & Paste Attack) が可能になります。

ここに漏れた code があるとしましょう。すると、以下の手順で攻撃者は code 所有者の RP 上のアカウントにログインすることができます。

  1. 攻撃者自身のブラウザで Authorization Request 発行
  2. 攻撃者自身の IdP 上のアカウントで IdP にログイン
  3. Authorization Response を途中で止める
  4. Authorization Response 中に含まれる code を被害者のものに置換 (state は置換しない)
  5. Code 置換済の Authorization Response を RP に送る

こうすると、RP が state を使った CSRF 対策を行っていても、RP は受け取った code を使って攻撃者を被害者としてログインさせてしまいます。

これが Code 置換攻撃です。

では、これを防ぐ手立てはあるのでしょうか?

Read on →