はじめに タイトルまんまなんですが困っています。世界の人たちどうしてんの こんばんはconvtoです。故あってgoogle sign inの仕様について調べてたんですが、表題通りの問題を見つけて頭を抱えています。 お客様の中に医師免許を持った有識者の方いらっしゃいましたら助けてください。 google sign inまわり、古いドキュメントも新しいドキュメントもいっぱいあって全体像があんまりつかめてないので僕が混乱してるだけかもだけど、だとしたらそれはそれで嬉しいのでとりあえず投下しておく [追記] インターネットから知見があつまりAndroidは大丈夫な雰囲気あります！記事の末尾に追記してます iOSはまだnonce渡す手段見つかってないので引き続き調査中 & 有識者の意見お待ちしております なにが問題なの OIDCぽいのにnonceが指定できないから、session管理者がnonceの

皆さんこんにちは、とらのあなラボのY.Fです。 先日、弊社エンジニアが開発で関わっているCreatiaで、以下のお知らせが投稿されました。 【新機能のご案内】#クリエイティア にて、『パスワードレスログイン』機能をリリースいたしました。 パスワードの代わりに指紋や顔認証、PINコードを使って、スムーズかつ安全にクリエイティアにログインできるようになりました！ ▶詳細は下記記事をご参照くださいhttps://t.co/FzsVIAl7Sp— クリエイティア［Creatia］@ファンクラブ開設費無料！ (@creatia_cc) 2023年6月8日 弊社のサービスは、とらのあな通販やサークルポータル除いて、ほぼRuby on Railsを利用しています。 speakerdeck.com 今回の記事では、Ruby on Rails + WebAuthnについて、調べたことなどをまとめてみたいと思

ritouです。 Xを日々パトロールをしていると、共有/共用端末(これ正式な用語としてはどっちなん？以下、共有と呼びます。)でのパスキー利用について思いを馳せる人が目につくようになりました。 だいたいの人は 共有端末ではパスキーは使えない！完 という認識でしょうけれども、実際どうなんでしょうか？ 今回はもうちょっと解像度を上げるための細かい話をしましょう。 共有する範囲 まずは 共有端末と言っても、実は細かく色々あるんじゃないの? というところです。 サービスを利用するにあたって、ユーザーが専有できる範囲はどこなのか、複数ユーザーと共有する範囲はどこなのかというところがいくつかあるでしょう。 (A) 端末ごとにユーザーが異なる: 個人PCやモバイル端末を利用 (B) 端末のプロファイル(ログインユーザー)が異なる: 会社のPCに社員がログインして利用 (C) 端末のプロファイルは一緒、ブラ

ritou です。 これで話しました。 pwanight.connpass.com 発表資料と発表内容を公開します。 発表資料 speakerdeck.com 発表内容 台本チラ見しながら話したので実際にはこのとおりになってなかった部分もあります。 今日は、パスキーについて話します。 細かい自己紹介は省略します。 色々宣伝したいものがありますがブログに書きます。 今日の内容ですが、初めにパスキーの概要についてざっと触れます。 続いてWebアプリケーションにパスキーを導入するとなった場合にどこから手をつけるべきかというところに触れた後、一番の悩みどころになりそうなログインのUI/UXについて紹介します。 概要からいきましょう。 パスキーの紹介記事もたくさん出ているので要点だけまとめます。 パスキーとは「パスワードが不要な認証方式」であり、それを支える仕様はFIDOアライアンスとW3Cにより策

こんにちは、ritouです。 β公開から少し時間が経ってしまいましたが、1Passwordのパスキー対応について確認して整理しました。 www.publickey1.jp これまでAppleのiCloud KeychainやAndroidのGoogleパスワードマネージャーなどが プロバイダとしてのパスキーのサポートをしてきた中で、1Passwordが同様の対応をすることでクロスプラットフォームなパスキー利用環境が整うのか？と注目が集まっています。 個人的に1Passwordを活用しているので、使い勝手を見てみました。 環境は Chrome バージョン: 114.0.5735.133 @ macOS です。 1Passwordのβ版の拡張機能を有効にすることで動作確認ができます。 Relying Partyにはwebauthn.ioを利用します。 webauthn.io パスキーの生成/登

English version of this article is available here はじめに こんにちは、CTO室 IDサービス開発部のyamato(@8ma10s)です。 マネーフォワード IDという、当社サービス向けのIdPを開発しています。 今回このマネーフォワード IDにおいて、パスワードを使わずに、生体認証などを利用してログインできる「パスワードレスログイン」という機能をリリースしました。 また、今回のリリースでは、既にいくつかの他社サービスで導入されているような通常のパスワードレスログインUIではなく、「Passkey autofill」という、ブラウザの自動補完を利用する新しいタイプのパスワードレスログインUI を（恐らく日本のサービスで初めて。エンドユーザーの目に触れるサービスという意味では、おそらく世界でも初めて）導入しています。 私達がどういった過程で、

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

ritouです。 idcon の Yahoo! JAPAN の人の資料と動画を見たメモです。 www.docswell.com youtu.be 2画面のログインUX p5 2画面か一回でやるかの話は、個人的にこだわっているスキャンの話もありますね。 Y!JはFederation(RP側)をやっていませんが、マネフォのようにパスワード認証/FederationがあるところにWebAuthnを追加する場合にどうすべきか、みたいなのは別途どこかで整理したい気がしています。 推測 Platform Authenticator だけはなく YubikeyとかのRoaming Authenticatorに対応してる場合、リセットした場合も同じことが起こりそう。 そもそもFIDOはブラウザ - 認証器と多段の処理になっているのでブラウザレイヤーでの完全なコントロールってのも難しそう。 例えば、Andr

いろんなアイデンティティ管理系製品やサービスの実験の記録をしていきます。 後は、関連するニュースなどを徒然と。 こんにちは、富士榮です。 もうすでに記憶の彼方ですがLINEさんは過去にFIDO2サーバーをOSSで公開する！と宣言していました。それが遂に公開されました！素晴らしい！ ということでとりあえず動かしてみました。（まだ中身は全然みてません、単に動かしただけです） LINE Security R&DチームがFIDO2認証標準を実装したFIDO2 ServerをOSSとして公開しました。 FIDO2-Serverは、FIDO2の登録と認証の主要部分を提供します。さまざまなWebブラウザとOSプラットフォーム、および生体認証をサポートします。#fido2 #LINE_OSShttps://t.co/o4EhxpyWAi — LINE Developers (@LINE_DEV) Augu

おはようございます ritou です。 8月ですよ。お仕事の進捗大丈夫ですか？ 最近、Google方面からDecoupled AuthNの香りがしたので追ってみました。 何の話? この話です。 developer.chrome.com WebOTPとは? Webアプリケーションがモバイル端末でSMS経由のOTP認証をしようと思った時、画面に「認証コードを送信しました」なんて出た後にSMSを確認できるアプリを起動して確認してまたブラウザに...とかをやったことがある人は多いでしょう。 WebOTPとは、モバイル端末上のブラウザであればアプリの切り替えをせずにワンタップでSMSで受け取ったOTPの値を読み込んで検証リクエストに繋げられる、しかもSMSを発信したWebアプリを特定できるフォーマットになっていることでフィッシングサイトからはこのフローを使えなくするような仕組みのことです。 web.

こんにちは、最近ブルグミュラー15曲目（原曲No.20）が終わった内波です。 「じゃあ小学校3年生くらいだね」と言われて少しだけしょんぼりした瞬間もありましたが楽しくやっています。 このブログではだいぶご無沙汰していましたが、最近、我々の会社の立場がかなり稀有なもので、そこで得られている情報をもっと多くの人に広く共有していくべきだな、と感じるようになったので、久々に筆をとりました。 何がそんなに珍しい立場かというと、他社が提供するAPI、その中でも特に、単純な「機能」としてのAPIではない、ユーザーの認可を受けてその代理人として利用するAPIを、これほど多く扱っている企業はなかなかないんじゃないかな、というものです。 はじめに この記事で取り扱うAPI API（アプリケーション・プログラミング・インターフェース）という単語は非常に広い意味で利用されるものですが、この記事でフォーカスするもの

こんにちは、ritou です。 最近のあれこれでIDaaSと呼ばれる機能に注目が集まっているような気がしますが、どうしてもフロントエンドでの導入部分が目に付きます。 「新規サービスで使っていこう」ならまだしも「既存のを何とかしたい」みたいな場合にフロントエンドまでごっそり変えるのなんて腰が重くなって仕方ない感じでしょう。 そこで今回は、REST APIを用いた新規導入、移行というアプローチもあるのかなという話を書いておきます。 SPAとなると当然フロントエンドの振る舞いに注目されるけど、Deviseからの...を考える人たちはこの辺りから攻めるのもアリかと思う。ちゃんと整理して考えよう。https://t.co/fwhoA6wtjx— 👹秋田の猫🐱 (@ritou) 2020年8月19日 IDaaS の REST API この辺りをみてみてはどうでしょう。 Firebase Authe

The Ultimate Guide to handling JWTs on frontend clients (GraphQL) JWTs (JSON Web Token, pronounced 'jot') are becoming a popular way of handling auth. This post aims to demystify what a JWT is, discuss its pros/cons and cover best practices in implementing JWT on the client-side, keeping security in mind. Although, we’ve worked on the examples with a GraphQL clients, but the concepts apply to any

こんばんは、ritouです。 ID Tokenがやりとりされている背景 ちょっと前にこんな話がありました。 blog.ssrf.in この id_token が JWT になっていますので、これを Authorization: Bearer $ID_TOKEN というヘッダにして oauth2-proxy で保護されているアプリケーションへ送信するだけです。 docs.aws.amazon.com Authorization ヘッダー (または、オーソライザー作成時に指定した別のヘッダー) に ID トークンを含めます。 この「ID TokenをAuthorization Headerに指定して保護されているっぽいリソースにアクセスする行為」は一体何なのかというお話です。 ある有識者はOAuth 2.0のProtected ResourceをID Tokenで保護することについての投稿をし

追記 2020-05-13 この方法に問題があることをご指摘いただきました。本来関係ないクライアントがリソースサーバーにアクセスできる問題がありますので、取り急ぎこの方法は非推奨であることを書いておきます(では、どのようにすればいいのかというところをまた後日追記します)。 リソースサーバーと全く関係の無いクライアントが、全く関係のない文脈で正当に取得した ID トークンを用いて、リソースサーバーの API にアクセスできてしまうと思われます。リソース側が evil かどうかも関係なく、むしろリソースサーバーは騙される側ですね。図を参照してください。 pic.twitter.com/kKCZohOgu2 — Taka@Authlete, BaaS for OAuth 2.0 & OpenID Connect (@darutk) May 13, 2020 追記 2020-05-18 結論として

おはようございます、ritouです。 (⚠️認可イベントの識別子のあたり、ちょっと見直しました！最初に見ていただいた方はもう一回どうぞ！) 前回、ハイブリッド型と呼ばれる OAuth 2.0 のトークン実装について書きました。 ritou.hatenablog.com その続きとして JWT(JWS) + RDBでできる実装例を紹介します。 理解するにはそれなりの OAuth 2.0 に関する知識が必要になるかもしれませんが、よかったら参考にしてみてください。 何を考えたのか OAuth 2.0のRefresh Token, Access Tokenを考えます。 要件から整理しましょう。 要件 結構ありますが、最低限の OAuth 2.0 の Authorization Server を実装しようと思ったらこれぐらいはやらないといけないでしょう。 RFC6750 で定義されている Bear

お疲れ様です、ritou です。 OAuth 2.0やOIDCの入門書(?)を読み終えた開発者の方に、仕様を理解していくための次のステップは何があるかを聞かれました。 そもそもそんなこと言う人は クライアントを実装したい(しなければならない) 認可サーバーを実装したい(しなければならない) セキュリティエンジニアを名乗っていてこの分野を抑えときたい ただ単純に興味がある : そんな人いる？ とかそんな感じな気はしますが、基本的なフローを乗り越えた先に広がる仕様沼への潜り方に戸惑っておられるようでした。 そこで、いわゆる RFC6749/6750/7636 あたりを完全に理解した開発者が山ほどある仕様にどう立ち向かっていくかを考えます。 仕様にも色々ある IETF の OAuth関連の仕様、いっぱいあります。密です。密です。みみみみみみみみ... tools.ietf.org 去年に一回まと

技術書典8で頒布予定でした。 ## 概要 ユーザーのIDを管理するのはWebサービスを展開する上で必要になりますが、独自で実装するにはハードルが高いです。外部のサービスを利用することでユーザーのサインアップとサインインを比較的簡単に実現できます。この本ではCognito User Pools、Auth0、Firebase Authenticationを中心にサービスの紹介と比較をします。 ## 本書の目的 「認証サービスCognito Auth0 Firebaseを比べる」を手にとっていただき、ありがとうございます。筆者はこれまで、CognitoUserPoolsを利用してオンプレミスで実装されていた認証システムの移行や、Keycloakを利用したシステムの構築を担当してきました。そのなかで、認証の機能を提供するサービスは数多くあるにもかかわらず、サービスを比較するような情報があまりないと