Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

タグ

ブックマーク / ritou.hatenablog.com (4)

  • 「使える人にだけ使わせる」 ~ マネーフォワード IDのログインUXから見るパスキー普及のポイント - r-weblife

    ritouです。 いよいよドコモさんもパスキー対応が始まりましたね!いや、これを書いている時点ではまだです。 k-tai.watch.impress.co.jp それよりも、今回はマネーフォワード IDのパスキー対応に注目します。 corp.moneyforward.com (4/5追記) マネーフォワード側からも解説記事が出ていました。この記事で言いたいことが全部書いてあります。 moneyforward-dev.jp ブラウザのパスワードマネージャー機能を利用したパスワード認証のUX パスキー対応に触れる前に、マネーフォワードIDのパスワード認証のUXから見ていきましょう。 マネーフォワードの「メールアドレスでログイン」のフローを何も考えずに使うと、最初にメールアドレスを入れてからパスワード入力を求めるUXになっています。 このようなUXでブラウザのパスワードマネージャーの機能を使う場

    「使える人にだけ使わせる」 ~ マネーフォワード IDのログインUXから見るパスキー普及のポイント - r-weblife
    asyst
    asyst 2023/04/04
  • OAuth認証とは何か?なぜダメなのか - 2020冬 - r-weblife

    こんばんは。ritouです。 Digital Identity技術勉強会 #iddance Advent Calendar 2020 1日めの記事です。 qiita.com 初日なのでゆるふわな話をしましょう。 何の話か もうだいぶ前ですね。9月のお話です。こんなTweetを見かけました。 社内Slackにいる「OAuth認証」と書くと訂正してくれるbotが丁寧な解説をするようになっていた 認証(Authentication)と認可(Authorization)は間違えやすいわりにミスると甚大な被害をもたらしがちなので、常日頃から意識を高めていきたいですね pic.twitter.com/oVQxBgZcHS— greenspa (@greenspa) 2020年9月28日 このbotに対する思うところはもう良いです。 今回は、「OAuthの仕様に沿ってID連携を実装するいわゆる"OAut

    OAuth認証とは何か?なぜダメなのか - 2020冬 - r-weblife
    asyst
    asyst 2020/12/01
  • SPAなClientがトークンを安全に扱えるかもしれない拡張仕様「OAuth2.0 DPoP」とは - r-weblife

    おはようございます、ritou です。 今日は日頃の情報収集方法の一つである Mike Jones氏のブログ記事に書いてあったドラフト仕様のご紹介です。 self-issued.info The specification is still an early draft and undergoing active development, but I believe the approach shows a lot of promise and is likely to be adopted by the OAuth working group soon. まだDraft中のDraftな状態ですが、まいくたんの推し感が出ているのでざっと見ておきましょう。 OAuth2.0 DPoPとは? tools.ietf.org This document describes a mechanism

    SPAなClientがトークンを安全に扱えるかもしれない拡張仕様「OAuth2.0 DPoP」とは - r-weblife
    asyst
    asyst 2019/04/20
  • 特定条件下におけるOAuth 2.0の認可応答を奪取されるリスクとその対策について - r-weblife

    こんにちは、ritouです。 やっと”なんちゃらAdvent Calendar”がおさまり、これからは”一年を振り返って(遠い目”みたいな記事が増えることでしょう。その間のタイミングを狙います。 何の話か mixi Platformが導入したっていうOAuth 2.0のCSRF対策拡張を使ってみた - r-weblife の最後にちょっと書いたんですけど、モバイルアプリでOAuth 2.0を使う際にやっかいな問題が残ってました。 今回は、「ネイティブアプリケーションからOAuth 2.0を使うとき、特定の条件下において、正規のClientではない悪意のある第3者に認可応答を持って行かれて、その結果Access Tokenを取得できちゃうリスクがあるよね。どうしようか。」っていう話です。 条件っていうのは、 OAuth 2.0のClientはネイティブアプリケーションであり、Client C

    特定条件下におけるOAuth 2.0の認可応答を奪取されるリスクとその対策について - r-weblife
  • 1