症状検索エンジン「ユビー」 では、ローンチ当初から Firebase Auth (GCP Identity Platform) を使っていましたが、OIDCに準拠した内製の認証認可基盤に移行しました。 認証認可基盤そのものは m_mizutani と nerocrux と toshi0607(退職済) が作ってくれたため、僕は移行のみを担当しました。 結果として、強制ログアウトなし・無停止でビジネス影響を出さずに、年間1000万円以上のコスト削減に成功しました[1]。その移行プロセスについて紹介します。認証認可基盤そのものの紹介はあまりしません。 移行した理由 大量の匿名アカウント ユビーでは、アクセスした全ユーザーに対して自動的に匿名アカウントを発行しています。これにより、ユーザーがアカウント登録しているかどうかに関わらず、同じID体系で透過的に履歴情報等を扱うことができます。アカウント
iOS でも Web Push が送れる！microCMS と Firebase Cloud Messaging を使った実装方法 お初にお目にかかります(？) chot Inc. で Web エンジニアをしているすてぃんです。 もう 1 ヶ月前ですが iOS Safari でプッシュ通知に対応したバージョンのベータ版が発表されましたね。 Web のプッシュ通知は、シェアの大きい iOS が対応してくれなかったのであまり実用的ではありませんでしたが、これからは Web でも多くのユーザーに能動的に新着情報を伝えることができるようになります。 本記事では Firebase Cloud Messaging(以降 FCM と表記) を用いた Web Push 通知の実装方法を、架空のメディアサイトを実装しながら紹介します。 FCM 以外には microCMS と Next.js を使用します。m
みなさん2022年いかがお過ごしですか。macopyです。 この記事はPerl Advent Calendar 2022の9日目です。 追記: Firebase Advent Calendar 2022の9日目も空いていたので入れておきました。 今回はFirebase Authenticationを使っていたら、何もしていないのにログインできなくなったと言われて一心不乱で直した話をします。 Firebase Authenticationとは Firebase Authentication(以下Firebase Auth)とは、Googleのアプリケーション開発プラットフォームであるところのFirebaseの中にある、認証サービスです。 競合サービスとしてはAuth0で、つまりIDaaSとして使えます。専用品のAuth0よりは機能は少ないですが、複数のIdPを組み合わせてユーザの認証管理をし
January 28, 2022 Firebase で Google や Facebook といった外部認証を利用したログインを実施する場合 signInWithPopup または signInWithRedirect のメソッドを利用します。 参考：https://firebase.google.com/docs/auth/web/google-signin 大抵の場合 UI を独自に構築したいでしょうから signInWithRedirect の方を利用することになるでしょう。 さて signInWithRedirect を呼び出した場合、自サイトから認証プロバイダー（例：Facebook）のページに飛び、その後また自サイトに戻ってくるといった遷移になります。 このときの認証プロバイダーからの戻り先は、リダイレクトを発生させた元ページになります。例えば /home というページで si
FCMトークンの仕様 Firebase Cloud Messagingを使ってアプリへのプッシュ通知テストをする際に、Firebaseコンソール上で対象デバイスのFCMトークンを登録する必要があります。 このFCMトークンがデバッグ中にいつのまにか変わっていることがあり、挙動を把握するためドキュメントで仕様を確認してみました。 OS毎に挙動が異なるようだったので、それぞれの生成・更新タイミングをメモしておきます。 Android 【参照】Android で Firebase Cloud Messaging クライアント アプリを設定する | Firebase 生成タイミング アプリを初めて起動すると、クライアント アプリのインスタンスの登録トークンが FCM SDK によって生成されます。単一のデバイスを対象にする場合、またはデバイス グループを作成する場合は、FirebaseMessag
On our app we are using "One account per email address". We want users to sign up using a specific authentication provider, which we keep track of, and stick with it. What I've noticed today is that if I log in using a Google or Facebook provider I can then send myself a password reset link to the associated email address, which allows me to use the email/password provider instead. There is a slig
Firebase Authentification は OAuth 2.0 フローにのっとったログイン方法以外にも Email/Password を使ったログイン方法も提供しています。 このログイン形式をちゃんと使おうとすると、これまでは Provider が担ってくれていたパスワードの編集、パスワードの再発行、メールリンクでのログイン、アドレスの本人確認など様々なことを考慮しなければいけません。 この記事ではそういった考慮をした Email / Password ログインに挑戦します。 基本的にはmanage-users, password-auth, email-link-authといった公式ドキュメントを読むと IPASS ログインに必要なことは書いてあるのですが、action URL を自前で用意するフローを採用するとそれらのドキュメントで賄えなくなり試行錯誤をたくさんしなければい
フィードバックを送信 Firebase プロジェクトのユーザー コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 Firebase ユーザー オブジェクトは、プロジェクトのアプリに登録したユーザー アカウントを表します。アプリには通常、多くのユーザーが登録されていて、プロジェクトの各アプリはユーザー データベースを共有しています。 ユーザー インスタンスは Firebase Authentication インスタンスから独立しているので、同じコンテキストで異なるユーザーを別々に参照しながら、各ユーザーのメソッドをどれでも呼び出すことができます。 ユーザー プロパティ Firebase ユーザーには、一意の ID、メインのメールアドレス、名前、写真の URL から構成される基本プロパティがあります。これらのプロパティは、プロジェクトのユーザー データベースに格
Ubie Discovery の @yukukotani です。 症状検索エンジン「ユビー」では Firebase Auth (GCP Identity Platform) をヘビーに使っています。その中で一部 Firebase Auth の想定を超えた使い方をしていて、それを実現するための無理矢理なハックを紹介します。 Capacitor 上で OAuth を動かす Capacitor (=WebView) 上で Web ブラウザと同じように OAuth をやろうとすると、以下のような問題に直面します。 Google などの認証プロバイダは WebView 内でのアクセスを弾く (参考) 認証プロバイダからのコールバックが端末のデフォルトブラウザで開かれてしまい、ネイティブアプリに戻ってこれない Capacitor の類似技術である Cordova でも同様の問題がありますが、Fireb
https://twitter.com/kuwahara_jsri のやってる朝活Twitterスペースで以下の記事を知りました。 もちろんこういったリスクを列挙、検討するのは重要なことなのですが、 Firebase Authentication関係ない話では あれ、仕様に関して勘違いしてる？ というのがいくつかあったので、再整理していきます。リスクは列挙することには業務上あまり意味はなく、評価され、リスクを受け入れるか外すかを判断するところが重要なので。 IDaaSは脆弱性を生み出すか IDaaS を導入することにより、逆に脆弱性が生まれることもあります。（中略） Firebase Authentication は他の IDaaS と比べて設定項目が少ないという特徴があります。 もちろんここに書かれてることは間違いではありません。ただ、少し実装にフォーカスが寄りすぎていると思っています。
はじめに こんにちは、株式会社 Flatt Security セキュリティエンジニアのぴざきゃっと (@pizzacat83) です。 認証機構を自作せずに導入できる Firebase Authentication は様々なアプリケーションにて利用されていますが、その特性を十分に理解せずに導入すると、実は不具合や脆弱性が生じることがあります。そこで本稿では Firebase Authentication を利用するうえで、注意しなければ不具合や脆弱性に繋がりうる 7 個の「落とし穴」について解説します。 はじめに IDaaS の利点と欠点 落とし穴 1. 自己サインアップ リスク 対策 落とし穴 2. ユーザーが自身を削除できる 対策 落とし穴 3. 他人のメールアドレスを用いたユーザー登録 リスク リスク 3-1. メールアドレス誤入力によるユーザー乗っ取り リスク 3-2. 他人にメー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
