プラットフォームアカウントに紐づけられたクレデンシャルを利用するユーザー認証について - r-weblife
おはようございます、ritouです。 何の話？ 最近のユーザー認証を取り巻く状況について、次の2つの事例の共通点を考えましょう Passkey(FIDOアライアンスが言ってるMulti-Device FIDO Credentialsの方)はFIDOクレデンシャルがApple/Google/MSといったプラットフォーム(など)のアカウントに紐づけられる仕組み Google Authenticator のクレデンシャル管理がデバイス単位からGoogleアカウントに紐づくデバイス間で同期されるように変わる これらは "クレデンシャル" と呼ばれる、秘密鍵やパスワードなどの "認証のための情報" をデバイス単位ではなくプラットフォームアカウント単位に保存/管理するというお話です。 そのおかげで、新しいデバイスを使い始める際にこれまで利用してきたサービスに対して色々と設定しなおすことなく、Apple
ファーストパーティーなアプリが使うOAuth/OIDCについてのお話 2019 春 - r-weblife
夜分遅くに失礼いたします。ritouです。 こういう記事を読むとうずうずします。おそらく病気です。 terut.hatenablog.com 森羅万象を担当しているわけではないので、OAuth/OIDCが使えんのか？って観点から書いておきます。 ファーストパーティーのOAuth/OIDC利用 単一サービス内でOAuth/OIDC使うことってあるのか?という問いには「条件によっては適用可能」といったふわっとした答えになりそうです。ﾌﾜｯ Webアプリ Webアプリでも例えばドメインいっぱいある、別れている系でOAuth/OIDCでつなぐケースはありそうですね。 Microsoft : https://www.office.com/ -> https://login.microsoftonline.com/common/oauth2/authorize?client_id=... OAuth
セキュアなトークンへのJWT適用について - r-weblife
おはようございます、ritouです。 こういう記事を読みました。 lab.astamuse.co.jp Webアプリケーションでセキュリティ対策のためにランダム文字列な文字列する場面が多々あります。例えば CSRF対策のトークン OAuthやOpenIDに使用するnonce, state メールの到達確認用URLのトークン パスワードをhashする際に使用するsalt これらの値は単に衝突しなければOKというものではありません。十分なセキュリティ強度を確保するためには推測不可能なランダム値を使う必要があります。 私は持病を持っているため、ついつい「あー、これJWTなら...」と考えてしまいます。 今回は、こういうセキュアなトークンの方にJWTを使ったらどうなるかというお話をざっくり書きます。 ちなみに、乱数生成の話に異論を唱えるわけではありません。 今回の要件にある 衝突しない 推測不可能
なんとなくOAuth怖いって思ってるやつちょっと来い - r-weblife
こんばんは、ritouです。 Twitterの問題が発覚した際、こんなgistも書きました。 gist:5053810 · GitHub 今朝、こんなTweetしました。 https://twitter.com/ritou/status/317429458657222657:twitter:detail:left gistに書いた通り、私の考える今回の問題の本質はoauth_callbackの管理、その一言に尽きます。他に2legged OAuthが入るとごちゃごちゃするので、OAuth 1.0の実装のポイントについてまとめてみました。 なんとなくOAuth怖いって思ってるやつちょっと来い from Ryo Ito もちろんこれだけではわけがわからないと思うので、説明が聞きたければどこかで話してもいいです。ぜひ声をかけてください。 普段は秋田にいますが、唯一この勉強会にはよく参加しているの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
