OAuth.jp

MVP になったことですし、早速 Azure 常に Windows Server 2016 の VM 立ち上げて、次期バージョンの ADFS を動かしてみました。

想定ユースケースは、Native App とその Backend Server があって、Backend Server が Native App 向けに提供している API 用の Access Token も、ADFS が発行するというものです。

まさしく今後エンプラで増えていくであろうパターンですね。

Setup Hybrid Client on ADFS

ADFS Manager に “Application Groups” っていう設定が増えてるんで、そこから “Native Application and Web API” ってのを選択して、Connect RP (= OAuth Client) を登録します。

スクショいっぱい撮るのが面倒なのですっ飛ばしますが、こんな感じで Native App とその Backend Server を ADFS に “Application Group” として登録しました。

ちなみに、この時 Backend には特に Native App と別の client_id が発行されたりはしません。

ここまでで、ADFS 側の準備は完了です。以降、こちらの gist に沿って、Step by Step で見ていきます。

2016年度の Microsoft MVP Award を受賞させていただきました。

これもひとえにあんのパパのおかげです。パパは2007年4月 Microsoft 入社ということなので、僕が新卒になったころからの MS エバンジェリストってことっすよ。

通常であればにいさんと呼びたいところですが、今回新たな MVP も産んだことですし、Identity 業界の慣習にならって積極的にパパ呼ばわりしていきたいとおもいます。

また、Award のカテゴリーは “Microsoft Azure” ってなってたので、ふぁらおぅにぃさんが腹ちがいのにぃさんになった感じですかね、きっと。

どこまで今回の MVP Award のカテゴリーにマッチしてるのかはよくわかってないんですが、僕がいま興味あるエリアは AzureAD & ADFS の Connect サポート、Graph API、Windows 10 の FIDO サポートあたりなんで、その辺りでいろいろ遊びながらこのブログとかで記事書いていければいいなと思います。

もちろんエディタは Visual Studio Code で。(まじこいつ起動はえー！Atom より圧倒的に起動はえー！！)

とりあえず Microsoft Edge の FIDO 実装で遊ぶためにも、Surface Pro4 を買わないとですね！

ということで、つい先日 Windows Server 上で新規ファイル作成すらできなくてがく然とした Windows 音痴な僕ですが、今後ともよろしくお願い致しますm m

ps.
新規ファイル作成は、右クリックじゃなく、メモ帳開いて [Ctrl] + [S] な。

昨日を最終出社日として、GREE 正社員生活を終えました。4月からは独り会社作って独立します。

転職じゃなくて独立で、契約形態変えて GREE さんともお仕事する可能性十分あるので、あまり退職っていう実感はないのですが、これもまぁ一応退職エントリー…ですかね？

新会社での業務内容としては、Identity まわりのコンサルとか技術支援とかをメインでやる予定。

ありがたいことにすでに数件4月以降の仕事依頼もいただいており、気軽に新しい案件受けづらい状況なのですが、もし興味あればご連絡いただければと思います。

ID の専門家として仕事しつづけるとしたら、1社に閉じるより数社の仕事同時にこなす方がいいんじゃないかとか、そういう流動的に動ける人もこの国に数人いたほうがいいんじゃないかとか、そういうのが独立のきっかけとしてあるので、いろんな会社のお話聞いてみたいです。

「OAuth 認証」って言葉が出てくると、「認証と認可は違う」とか言い出す人が出てきて、大体の場合「OAuth 認証」言ってた人たちがやりたいことの話とはズレた議論が始まるので、もういっその事「OAuth 認証」とは何かを定義してみましょうかね。

「OAuth 認証」で Relying Party (RP) がやりたかったこと

RP (OAuth Client) は、ブラウザの前にいる人を、認証したかったんですよね？

もう少し正確にいうと、ブラウザの前にいる Entity が、RP 側で把握しているどの Identity と紐付いているか、というのを知りたかったんですよね？

いきなり Entity とか Identity とかいう専門用語が出てきてアレですが、そのあたりのことは先日の OpenID TechNight #13 でもお話ししたので、以下のスライドの Entity・Identity・Authentication・Authorization のあたりのページを見てください。

で、あるサービスが End-User を認証したいって思った時って、普通は当該サービスが事前に当該 Entity に対して ID と Password を登録させて Identity Record (「サービスアカウント」と言ってもいい) を作成し、後日当該 Entity が当該サービスに訪れた際は登録済みの ID と Password を提示させて当該 Entity に紐づく Identity を確定するわけです。

でも Identity Federation (上記スライドでは「ID 連携」と表現している) という手法を使うと、外部のサービス (Identity Provider, IdP) の Identity を当該サービス (Relying Party, RP)の Identity と紐付けて管理することで、End-User から直接パスワードを預からなくても、ブラウザの前にいる Entity (= End-User) に紐づく IdP 側の Identity に紐付いた RP 側の Identity を確定できるので、結果として End-User に紐づく RP 側の Identity を確定することができます。

で、どうやって IdP と RP がそれぞれに管理している Identity を紐付けるのか、というのが、Federation Protocol の肝なわけですが、「OAuth 認証」というのはその一種です。

OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る – Qiita ってのになんかフォローアップしろよ的なのが来たので。

ざっと読んだ感想としては、「OpenID Connect の OPTIONAL な機能全部実装したら、そら大変ですね」という感じ。（Authlete に関しては、OpenAM みたいな感じで使われる、OpenAM よりはるかに簡単に使える代わりに有料の何かなんだろうな、というイメージです）

OAuth は必要なのか？

• Basic 認証は死んだ。
• ユーザー単位での API のアクセスコントロールがしたいです。

っていう前提で話すると、OAuth 以外まともな選択肢が無いんじゃないでしょうか。

OAuth の各種 Extension (RFC 6749 & 6750 以外にいろいろある) に関しては、適宜必要なのを実装すればいいんだけど、どれが必要なのかを選ぶのが大変なのは事実で、そこのベストプラクティスとかユースケースごとのガイドラインは今後の課題。IETF OAuth WG の中の人たちも、それは認識している。

「OAuth 認証」とは

OAuth は「End-User (に信頼された OAuth Server) が OAuth Client のアクセス権限をコントロールする」というコンテキストにおいての標準化されたプロトコルであって、「Identity Provider (IdP) が End-User を認証した結果を受け取って、Relying Party (RP) が (IdP への信頼を元に) End-User を認証する」というコンテキストで OAuth を使うユースケースが「OAuth 認証」と呼ばれるやつです。

後者のコンテキストで、OAuth は何も標準的な仕様を定めてはいません。

IdP が End-User を認証した結果を RP に伝える方法 (ID Token 相当) や、そのコンテキストで求められることが多い認証されたユーザー属性情報の取得方法 (UserInfo 相当) については、完全に各 Platform が独自に API を提供してるだけなので、そういう意味では「OAuth 認証」ってのは「オレオレ Connect」みたいなもんですね。

まぁでも「オレオレ OAuth」の上で「オレオレ Connect」やる「JWT 認証」よりはマシなんじゃないかなっていう気はします。