Sign in With Apple の特徴分析 (1) のつづき。
文章でつらつら書いても結局わかりづらいもんはわかりづらいんで、もう箇条書きで淡々と。
これだけそろってれば、あと最後の 要調査 ってとこを各自必要に応じて調べるなり、誰かがこの記事にコメントしてくれるなりすれば、一通りみなさんのサービスの設計に落とせるんでは無いかと思います。
※ 落とせない人は 僕 (= YAuth.jp 合同会社) に仕事を依頼する という手もありますw
Read on →前記事 で書いたように、ここ数日 Sign in with Apple 用の RubyGem 作りながら、Sign in with Apple の特徴というか、他の IdP との違いみたいなところいろいろ調査したので、現時点での Sign in with Apple に対する雑感をまとめておきます。
個人として Apple Developer Account 使ったことしかないんで、会社として Developer 登録してる時の Team の扱いとかよくわかってないんですが、Apple Developer Account 登録すると Team ID ってのが割り振られます。個人だと 1 Developer Account に 1 Team ID。
この1つの Team ID の下に、複数の子 App ID が登録可能です。1 iOS App についき 1 App ID。
さらに、App ID には “Primary” という概念もあり、1つの Primary App ID の下に複数の App ID を登録することができます。
ここまでは、お仕事で実際に iOS App 作ってる人たちにはきっと当たり前な話なんだと思います。
そして、Primary App ID の下に App ID の代わりに Service ID っていうのが登録できます。
Service ID っての設定画面には Sign in with Apple 関連の設定項目しかないから、これは今回初めて出てきたものなのかもしれませんね。
で、iOS App で Sign in with Apple 使う場合は App ID というのが OAuth Client に該当し、Web とか Android とかで Sign in with Apple 使う時は、 Service ID というのが OAuth Client に該当するようです。
1 Team ID の下に複数 App ID が登録され、1 App ID の下に複数の子 App ID と Service ID が登録され、iOS/Mac Native の世界では App ID が、それ以外では Service ID が OAuth Client となる。
ここまではいいですね？いや、正直間違ってるかもしれんけどw
そして、Client の鍵 (Client Secret を生成する為の秘密鍵、詳しくは後述) を別途生成するのですが、この鍵は Primary App ID 毎に登録することになります。
鍵は Key Rotation のことも考慮してか、1 Primary App ID に複数同時に登録できます。
ただ、1 OAuth Client に 1 Private Key、という単位ではないので、鍵管理のやり方は普通の OAuth Client の場合と異なるやり方が必要になる Developer さんもいるかもしれませんね。
Read on →iOS App に Apple ID でログインできたらいいのになぁ〜と思い続けてはや数年、ついにそんな時代がやってきましたね！
ということで、FB Connect 登場時の fb_graph gem リリース以来のスピード感で、Sign in with Apple 用の ruby gem をリリースしてみました。
ついでに Rails のサンプルアプリも。
github.com/nov/signin-with-apple
このサンプルアプリはこちらで動かしてるので、試したい方はどうぞ。
signin-with-apple.herokuapp.com
Sign in with Apple は OpenID Connect を採用してるんですが、現状では Native SDK でしか email や fullName は取れないようです。
そのうち UserInfo API が出てくると思うんで、出てきたら apple_id gem でもサポートしようかと思います。
ps.
とりあえず Terminal で動かすだけでいいよって方はこちらのサンプルをどうぞ。
https://gist.github.com/nov/993a303aa6badd8447f7b96fb952088e
ついに Amazon Echo Plus の購入券当選通知が来たので、Echo Plus と一緒に Nature Remo を買いました。
エアコン推しですが、テレビのリモコン等、赤外線飛ばすリモコンならなんでも対応できる、素敵な「スマートリモコン」です。
Nature Remo アプリでセットアップして、アプリからリモコンつけたり消したりできるのも素敵ですし、アプリで設定しといたら iPhone が Nature Remo から 30m 以上離れたら自動でエアコン切るルールとか設定しとけるのも素敵です。
が、やはりここは
「Alexa、エアコンをつけて」
ってやりたいですよね。
Read on →脆弱性の内容に関する 日本語解説はこちら。
で、実際に脆弱性が存在してた実装もみてみると、OneLogin 製の ruby-saml だと、該当の脆弱性はここで修正されてます。
Fix vulnerability CVE-2017-11428. Process text of nodes properly, ign… · onelogin/ruby-saml@048a544
この行 がまさにメインの修正箇所なんですが、いままで REXML::Element#text 呼んでいたものを、すべて REXML::Element#texts を join するように変更してますね。
でも、そもそもこれ署名検証の部分の修正が含まれてないのはなぜでしょう？
署名検証してるのはここ なんですが、これ、よくみると REXML じゃなくて Nokogiri 使ってますね。REXML には XML 正規化の機能がなかったから、その部分だけ Nokogiri 使ったんですかね。
なら全部 Nokogiri 使えや。
2つの XML Parser を1つの実装の中で混在させてる時点で、すごいやな香りしますよね。ruby-saml は今回の脆弱性修正でも、その状況は変わってないので、Ruby で SAML 実装するなら libsaml (digidentity/libsaml) に移行した方が良さそうですね。
ちなみに、OpenID Connect ならそんなことないのかっていうと、当然あります。ruby-jwt と json-jwt を混在させてる NIST の RP サンプル とかね。
ruby-jwt に JWK まわりの機能がないから json-jwt を JWK のためだけに使ってて、それ自体はまぁそんな悪い予感しないけど…
なら全部 json-jwt 使えや。
