Sign in With Apple の特徴分析 (2) - OAuth.jp
Sign in With Apple の特徴分析 (1) のつづき。 文章でつらつら書いても結局わかりづらいもんはわかりづらいんで、もう箇条書きで淡々と。 これだけそろってれば、あと最後の 要調査 ってとこを各自必要に応じて調べるなり、誰かがこの記事にコメントしてくれるなりすれば、一通りみなさんのサービスの設計に落とせるんでは無いかと思います。 ※ 落とせない人は 僕 (= YAuth.jp 合同会社) に仕事を依頼する という手もありますw 各種 ID とその対象 (?) 範囲 Developer が使う IDs 等 Team ID 個人向け Apple Developer Account では Developer Account に1つ Enterprise 向け Apple Developer Account での話はしらない App ID App Store に並べるアプリ毎に1つ
Rubygem for Sign in with Apple & Rails Sample App - OAuth.jp
iOS App に Apple ID でログインできたらいいのになぁ〜と思い続けてはや数年、ついにそんな時代がやってきましたね！ ということで、FB Connect 登場時の fb_graph gem リリース以来のスピード感で、Sign in with Apple 用の ruby gem をリリースしてみました。 github.com/nov/apple_id ついでに Rails のサンプルアプリも。 github.com/nov/signin-with-apple このサンプルアプリはこちらで動かしてるので、試したい方はどうぞ。 signin-with-apple.herokuapp.com Sign in with Apple は OpenID Connect を採用してるんですが、現状では Native SDK でしか email や fullName は取れないようです。 その
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
OpenID Connectはそんなに大変かね？ - OAuth.jp
OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る – Qiita ってのになんかフォローアップしろよ的なのが来たので。 ざっと読んだ感想としては、「OpenID Connect の OPTIONAL な機能全部実装したら、そら大変ですね」という感じ。（Authlete に関しては、OpenAM みたいな感じで使われる、OpenAM よりはるかに簡単に使える代わりに有料の何かなんだろうな、というイメージです） OAuth は必要なのか？ Basic 認証は死んだ。 ユーザー単位での API のアクセスコントロールがしたいです。 っていう前提で話すると、OAuth 以外まともな選択肢が無いんじゃないでしょうか。 OAuth の各種 Extension (RFC 6749 & 6750 以外にいろいろある) に関しては、適宜必要なのを実装すればいいんだけど
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
