SPA認証トークンをどこに保存するかは論争が絶えません。localStorageやCookieがよく使われますが、Auth0は違う方法を採用しています。この記事では、Auth0のトークン管理の方式を理解でき、トークン管理上のセキュリティへの理解を深めることができます。 SPAの認証トークンをどこに保存するか ブラウザでトークンを保存できる場所 保存場所の比較 メリット・デメリット Auth0のアプローチ トークンはインメモリに保存 OpenID Connect準拠とトークン取得のUI/UXの悪化回避を両立 Auth0のjsライブラリ ログイン アクセストークンの（再）取得 図解 ログイン アクセストークンの（再）取得 自サービス内の認証だけのもっと簡易な構成 ログイン IDトークン取得 まとめ SPAの認証トークンをどこに保存するか React やVueで認証付きSPA（Single Pa
即戦力人材と企業をつなぐ転職サイト「ビズリーチ」は2009年にサービスを開始し、スカウト可能会員数は190万人以上（2023年1月末時点）のユーザーにご利用いただくサービスに成長しました。 今回、その「ビズリーチ」の認証基盤としてIDaaS（Identity as a Service）のOkta Customer Identity Cloud（Powered by Auth0）（以下Auth0という）の導入を行いました。 本記事では認証基盤を刷新するに至った背景とAuth0を用いて100万を超えるユーザーをログアウトさせることなく移行した方法についてご紹介いたします。 前提 本記事で得られる情報 本記事を読むことで以下のような情報を得ることができます。 IDaaSを選ぶ理由 IDaaSを用いて認証・認可を運用中のプロダクトに組み込んだ事例 運用中のプロダクトに組み込む際に発生しうる課題と対
はじめに こんにちは、株式会社 Flatt Security セキュリティエンジニアのぴざきゃっと (@pizzacat83) です。 認証機構を自作せずに導入できる Firebase Authentication は様々なアプリケーションにて利用されていますが、その特性を十分に理解せずに導入すると、実は不具合や脆弱性が生じることがあります。そこで本稿では Firebase Authentication を利用するうえで、注意しなければ不具合や脆弱性に繋がりうる 7 個の「落とし穴」について解説します。 はじめに IDaaS の利点と欠点 落とし穴 1. 自己サインアップ リスク 対策 落とし穴 2. ユーザーが自身を削除できる 対策 落とし穴 3. 他人のメールアドレスを用いたユーザー登録 リスク リスク 3-1. メールアドレス誤入力によるユーザー乗っ取り リスク 3-2. 他人にメー
みなさま、認可の設計に苦しんでいるでしょうか？私は苦しんでいます。苦しまなかった瞬間などありません。昔「アプリケーションにおける権限設計の課題」を執筆しましたが、あれから3年以上が経ちます。 当時は認可の設計に関する情報がうまくまとまっている記事などほとんど無く、調べに調べて得たナレッジを書き記したのが上記の記事です。3年以上経ちますが、苦悩が今も特に変わっていないことが驚きです。 ただし、世の中的には認可のライブラリであったりサービスというのは少しずつ増えてきている印象があります(Auth0の OpenFGA であったりOsoの Oso Cloud 、Asertoの Topaz )。 認可の設計に関する記事も少しずつ増えている印象があり、その中でも本記事で紹介したいのがAuthorization Academyです。 これは認可サービスである Oso Cloud やOSSのライブラリ o
本資料について 本資料は日本大学文理学部情報科学科の開講科目「Web プログラミング」の教材として作成されました。本資料は下記のライセンスの範囲内で、当授業以外でも自由にご利用いただけます。 対象読者 本資料は、以下の教材を学習済み、もしくはそれと同等以上の知識を持っていることを前提としています。 React チュートリアル：犬画像ギャラリーを作ろう 基本情報技術者試験レベルの関係データベースの知識 本資料で学ぶこと 本資料では以下の内容を学びます。 Express と Sequelize による API サーバー開発 React と API サーバーの連携 Cross-Origin Resourcer Sharing React によるルーティング Auth0 によるユーザー認証 Heroku による API サーバーの公開 ライセンス この作品はクリエイティブ・コモンズ 表示 4.0
iCARE Developer Meetupは、月次で開催している株式会社iCAREが主催するエンジニア向けのLT勉強会です。18回目の今回は、Ruby on Railsをテーマに行いました。サーバーサイドエンジニアの越川氏からはToken認証機能について。 Rails APIモードで開発するときの認証用のトークンはどこに保存すればいいの問題越川佳祐氏：私からは、「Rails APIモードにおけるToken認証機能について」というテーマでLT（ライトニングトーク）をしようと思っていたんですが、スライドを作っていて「あれ、これ別にRailsだけの話じゃなくない？」と思ってしまいました。みなさんの中にも、そう思う方がいるかもしれないんですが、もうこれで作っちゃったのでご了承ください。 私は株式会社iCAREで、サーバーサイドエンジニアをしている、越川と申します。Twitterは@kossy07
こんにちは、柴田です。 今回は「会員制メディア」のチュートリアルを全3回に分けてお届けします。 === 認証編ページ作成編完成編=== 会員制メディアは、一部の記事は会員しか見れないような形式のメディアです。 ビジネスでは近年よくあるユースケースであり、もしかしたら個人ブログに導入してみても一風変わっていて面白いかもしれません。 また、応用すれば課金しないと見れない記事のような仕組みも作れると思います。 今回想定している仕様は以下の通りです。 記事一覧画面と全公開記事（/public配下）は事前生成をしておき、静的に配信する会員向け記事（/private配下）はログイン済みユーザーのみ閲覧可能とし、SSRで配信する Next.jsを用いてJamstackとSSRの合わせ技を行い、認証にはAuth0を用います。 1. Next.jsプロジェクトを用意まずは、Next.jsのプロジェクトを作成
はじめに こんにちは。 セキュリティエンジニアの@okazu-dm です。 この記事は、Auth0のアクセストークンの保存方法について解説した前回の記事の補足となる記事です。前回の記事の要旨をざっくりまとめると以下のようなものでした。 Auth0はデフォルトではアクセストークンをブラウザのメモリ空間上にのみ保存するin-memory方式であり、XSSへの耐性のなさ等の理由でlocalStorageで保存することを推奨していない しかし、XSSでアクセストークンを奪取できるのはin-memory方式でも同じのはず(検証は行いませんでした)。localStorage方式を過度に忌避する必要はないのではないか なお、Flatt Securityの提供するセキュリティ診断はAuth0に限らずFirebase AuthenticationやAmazon CognitoなどのIDaaSのセキュアな利用
※追記: 本記事の続編としてin-memory方式からアクセストークンを奪取するPoCを下記記事で公開しました。ぜひあわせてご覧ください。 はじめに こんにちは。 セキュリティエンジニアの@okazu-dm です。 この記事では、Auth0のSPA SDKでアクセストークンのキャッシュを有効化する際の考慮ポイントについて紹介し、それを切り口にアクセストークンの保存場所に関してin-memory方式とlocalStorage方式の2つについて解説します。 Auth0のようなIDaaSは昨今かなり普及が進んでいると思いますが、Flatt Securityの提供するセキュリティ診断はAuth0に限らずFirebase AuthenticationやAmazon CognitoなどのIDaaSのセキュアな利用まで観点に含めて専門家がチェックすることが可能です。 ご興味のある方は是非IDaaS利用部
はじめに 先日ふと Auth0 のダッシュボードを眺めていると、興味深い項目が表示されていました。 Passkey がある!!! なので、今回は Auth0 に搭載されたパスワードレス認証方式である Passkey の説明をしていきます。 なお、Auth0 の設定方法についてはAuth0 からリリースされた記事を参考にして、記載しています。 パスワード認証の課題 Passkey の説明をするまえに、パスワード認証の課題について見ていきます。 認証方法として当然とされているパスワード認証ですが、以下の 3 つの課題を持っています。 ① パスワードの使い回し ② 推測されやすいパスワードの使用 ③ フィッシングアプリへのパスワード入力 それぞれ見ていきましょう。 ① パスワードの使い回し ログインが必要なアプリにはそれぞれ異なるパスワードを使用するというのは皆さんご存知だとは思います。 とはい
Auth0の無料プランが拡大。月間2万5000アクティブユーザーまで、独自ドメイン、パスキーによるパスワードレス対応も 認証プラットフォームを提供するOkta社は、Auth0の無料プランを拡大したと発表しました。 Auth0は、認証や認可にかかわる機能がクラウドサービスとして提供されており、SDKを用いてWebアプリケーションやモバイルアプリケーション、デスクトップアプリケーションなどに組み込むことで、通常のログイン名とパスワードを用いた認証はもちろん、Active DirectoryやGoogle Workspaceなどとの接続、Facebookなどを用いたソーシャルログイン、パスキーによるログインなどを簡単に実現します。 また、不正ログインに対する防御機能なども備えています。 無料プランで月間2万5000アクティブユーザーまで対応 これまでの無料プランは、最大で月間7500アクティブユ
Next.jsとAuth0を使って読んだ本を管理するサイトを作ったので使った技術等を紹介します。 github どんなサイトか？ まずは、どんなサイトを作ったのかを紹介します。読んだ本の管理を行うサービスで、主な機能は3つです。 Google Book APIに登録されている本を検索して本棚に保存できる 登録されていないなくてもアプリ内で新しく登録できる。 今まで本棚に登録した本の合計ページ数・本の高さ・本の重さを表示。1ページ当たり0.5g、0.15mmで計算します。 画面遷移 1.トップ画面 アプリのトップ画面。「アカウント作成・ログイン」ボタンを押すことでログイン画面に遷移します。 2.ログイン画面 Auth0を使ったログイン画面。認証方法は2種類あります。 Googleアカウントを使ったログイン メールを使ったログイン 3.ホーム画面 今まで読んだ本を管理する画面。最近読んだ本の表
Auth0を始めとした様々な便利なSaaSがありますが、いざ業務で使おうとすると、社内・組織の承認が必要なるでしょう。 そんなときに便利なのが、IPAが公開しているクラウドサービス安全利用の手引きです。 中小企業の情報セキュリティ対策ガイドライン：IPA 独立行政法人 情報処理推進機構 付録6： クラウドサービス安全利用の手引き 本記事では、上記のクラウドサービス安全利用の手引きを参考にして、Auth0の関連リンクを紹介していきます。 まずは下記でAuth0の構成を見てから、Auth0の各ドキュメントを読むと用語が分かりやすいと思います。 おすすめの方 Auth0を使うにあたって、社内承認に必要な参考情報を知りたい方 はじめに 本記事の内容を参考にすれば、100％OKというわけではありません あくまでも参考情報であり、会社や組織などで最終判断をしてください Auth0の利用に関する文章を読
Leaner Technologies でエンジニアをしている @corocn です。 社内では IDaaS 利用していきたいねという機運が高まっているのですが、toB で SAML 対応の IDaaS について比較検討してみて難しいな〜と思ったところをまとめてみました。 前提 BtoB SaaS では、初期のプロダクトの領域を起点に事業領域を隣接する領域に広げていくことが多いですよね。バックオフィス向けの SaaS を開発しているメガベンチャーを見ているとそう感じます。 新しく立ち上げたプロダクトを既存のユーザーさんにも提供したい。そうなると、必然的に複数のプロダクトに対して共通で ID 基盤を持ちたくなるはず。認証ドメインを分離しようとすると、自前で作るか、KeyCloack などの OSS をベースに運用するか、IDaaS の利用を検討することになるでしょう。 最初は認証基盤も含めて
こんにちは。ROBOT PAYMENT （以下、ロボペイ）でエンジニアをしているtakamoriです。 私が所属しているチームでは、請求先マイページ機能を開発しており、その中でユーザー認証基盤をAuth0からCognitoへと移行させました。そこで今回は、Auth0からCognitoへのユーザー移行手順を書いていきたいと思います。 ※ 本記事ではAuth0やCognitoの環境構築は対象外で、それぞれの環境が構築済み前提となります。 移行手順 Auth0からユーザーをエクスポート Auth0ユーザー情報をCognitoユーザー情報へマッピング Cognitoへユーザーをインポート Auth0からユーザーをエクスポート Auth0からのユーザーをエクスポートするには、ExportUsersJob APIを利用します。GetUsers APIを利用して取得することも可能ですが1,000件の取得
IDaaSはなぜ注目を集めるのか Auth0は、2013年に創業された認証基盤サービスを提供する企業であり、既に日本を含む世界中で9,000社以上の導入実績を持っているという。そのような同社で首席アーキテクト責任者を務めているのが、ヴィットーリオ・ベルトッチ（Vittorio Bertocci）氏である。 現在、世界中で“認証管理業界の伝道師”として活躍している同氏は、Auth0へ入社する前にマイクロソフトに在籍していた。2001年、イタリア支社へ入社すると、2005年にはブログで発信していた内容が目に留まり、本社でエンタープライズデベロップメントのエバンジェリストとして活躍するようになる。 Auth0 認証アーキテクト責任者 ヴィットーリオ・ベルトッチ（Vittorio Bertocci）氏 約7年間エバンジェリストとして公の場でスピーチする傍ら、プロダクトチームや開発者、ユーザーとやり
Bill One Engineering Unit 共通認証基盤チームの樋口です。 Bill Oneでは昨年までAuth0を認証基盤として利用してきましたが、認証基盤を内製化することでコストを大幅に削減しました。 この認証基盤は、昨年12月に無事リリースされ、Bill Oneの認証を支えています。 今回は認証基盤の内製化に至った経緯と設計、移行プロセスについて紹介します。 Bill Oneについて 認証基盤に関する課題 解決方法の検討 IDaaS（Identity as a Service）について 設計とシステム構成について 認証基盤の設計 システム構成 アカウントの移行について メールアドレス・パスワードでのログインを利用しているユーザーの移行 SSO（Single Sign-On）の移行 振り返りと今後 ドメイン変更による問い合わせの増加 内製化によって体験の改善がスムーズに Bil
Hi, I’m Ryoichi Sekiguchi. ( @ryopeko ) I’m working as a Backend Engineer in Shippio. Today I will talk about our decision to choose Auth0 over AWS Cognito. Japanese follows English. What did we consider important?As a startup development team, we wanted to reduce our concerns about authentication. We then began to consider transferring the authentication infrastructure to an external service at t
BLOG Getting Unlimited Scalability with Okta Fine-Grained Authorization
請求管理ロボのエンジニアリングマネージャーの白坂です。 先月2022年2月に、請求管理ロボでは認証基盤としてAuth0を導入しました。 導入検討から4ヶ月ほどかけてリリースしたのですが、これまで独自で作り込んでいた認証の機構に対して認証基盤サービスを導入することになったため導入した経緯や当社でIDaaS選定に際してポイントになったことを紹介します。 現在稼働しているシステムへIDaaS導入を検討している方の参考になればと思います。 どうしてIDaaSを導入したのか？ 導入サービス決定のポイント 1. 導入のための実装コストが低い 2. BOT検知などのセキュリティ強化が容易 3. IDaaS利用コストは他のサービスと比べて高いが許容できた 導入するためのとったアプローチ 1. 要求のリストを作成 2. 導入候補のIDaaSを選定 3. 導入コストと拡張コストの見積もり 最後に どうしてID
タイトル はじめに：Auth0導入の動機と本記事で得られること Auth0のコアコンセプトを理解する テナント (Tenant): 分離と管理の基本単位 アプリケーション (Application): 認証・認可の対象 API (Resource Server): 保護対象リソース コネクション (Connection): 認証方法 Actions: 認証フローのカスタマイズ コアコンセプトのまとめ Auth0環境構築の実践 テナント戦略：開発・ステージング・本番環境の分離 アプリケーション設定：種類と主要パラメータ API（リソースサーバー）の定義と設定 認証フローの実装：詳細ガイド 適切な認証フローの選択 Auth0 SDKの活用（例：React SDKでの実装ポイント） コールバック処理、トークン管理とセッション (SPAにおけるベストプラクティス) Auth0 Actionsによる
📣 Hanko v2 Release: Build your custom login with the new JS SDK Modern Authentication. On Your Terms. Open source, privacy-first, and built to scale. Hanko is the fastest way you integrate passkeys, 2FA, SSO, and more—with full control over your data. Move between self-hosted and Hanko Cloud anytime. No lock-in, just Auth how it should be: secure, user friendly, and fully yours.
はじめに はじめまして、Drawerグループ所属のもりやです。 キャディは入社して約2年になりますが、ブログ記事を書くのは初めてです。よろしくお願いします。 私は入社時から 製造業データ活用クラウドCADDi Drawer の開発に携わっており、最初のRBACベースの認可を私が中心に実装しました。 その関係から、今はIDチームで認証認可周りの開発を担当してます。 今回は、CADDi DrawerでSSOをサポートしたことについて、主にAuth0の観点で書きます。 おことわり この記事は、Auth0をある程度使ったことがある方向けに書いています。 タイトルに「1年かけて」とありますが、開発着手からリリースまでの期間を指しています。 途中で他の機能開発をしていた期間も含まれており、丸々1年を全て開発に費やしたわけではない点にご留意ください。 CADDi Drawer とは 認証観点で簡単に書く
Oktaは米国時間3月3日、開発者向けのアイデンティティ管理プラットフォームのAuth0を約65億ドル（約7000億円）相当の株取引で買収する計画を発表した。買収は両社の取締役会は買収を承認している。Oktaの2022会計年度第2四半期（2021年7月31日締め）中に完了する見通しだ。 Auth0は2013年に創業した。9000社を超える法人顧客を抱え、70カ国以上の顧客にサービスを提供している。Oktaは、従業員や顧客の認証に利用されるID管理ツールを1万社超に提供している。 Oktaの最高経営責任者（CEO）Todd McKinnon氏は、声明で「開発者中心のAuth0のIDソリューションを『Okta Identity Cloud』と組み合わせれば、既存の顧客と将来の顧客に非常な大きな価値をもたらす」とコメントした。「デジタル化が進む世界で、アイデンティティーは仕事でも私生活でも、われ
みなさんは ID Token と Access Token の違いを理解していますか？ Access Token を使用した保護された Web API を実装する機会は何回かありましたが、理解して使っていたかというとそうではありませんでした。プライベートな Web API にアクセスするときは、Access Token を Authorization ヘッダーに Bearer で渡せばいいんでしょ? ID Token?? の認識で、なんとなく使っていたような状態でした。最近、認証・認可や OAuth 2.0 / OpenID Connect を勉強する機会があり、2 つのトークンの違いについてざっくりと理解できましたので、ブログにしてみました。 このブログでは、OAuth 2.0 / OpenID Connect に対応している Auth0 という IDaaS を使って、この 2 つのトー
TechCrunch Daily News Every weekday and Sunday, you can get the best of TechCrunch’s coverage. Startups Weekly Startups are the core of TechCrunch, so get our best coverage delivered weekly.
CX事業本部Delivery部のアベシです。 こちらの記事では、API Gateway + Lambda のREST APIに Auth0 + Lambda Authorizerの認可を導入する方法について紹介します。 前編、更編に分けて紹介します。 今回の前編ではLambda Authorizer と Auth0を使ったAPI Gatewayの保護の仕組みと、土台となるAPIのCDKコードについて紹介しようと思います。 Lambda Authorizer と Auth0を使った認可の仕組み 以下のフローで認可が行われます。 ① クライアントがAuth0に認可をリクエストする。 ② 認可されたらAuth0がアクセストークンを返す。 ③ クライアントがAPIコールする。その際にアクセストークンをヘッダーとしてAPI Gatewayに渡す。 ④ API GatewayがLambda Autho
Auth0 の Silent Authentication (サイレント認証)と Refresh Token Rotation (リフレッシュトークンローテーション)を完全に理解したい気持ちが急に高まってきたので書きます。 全体の流れとして React SPA with Auth0 での認可フローについて Silent Authentication (サイレント認証)について Refresh Token Rotation について まとめ みたいな流れで書きつつ、Silent Authentication や Refresh Token Rotation は何を解決しようとしているのか、それぞれのリフレッシュ方法でどのような挙動になるのか、などについて理解を深めていきたいと思います。 また、React SPA with Auth0 の認可フロー部分のイメージを沸かせるために以下のサンプルリ
はじめに Auth0いいですよね! 認証/認可をほとんどおまかせすることができて、ログインページも作ってくれるし、セッション管理もしてくれる。SPAでも。SDKで簡単にトークンの更新をiframeでよしなにやってくれたりと、かなり神ががっているIDaaSです。 そんなAuth0にOrganizationsという機能が2021年4月にリリースされていました。 最近はReactを触ったり、Kotlinを触ったりと全然別のことばかりしていたので、キャッチアップが遅れてしまったのですが、色々試したりして、辛かったマルチテナントの認証/認可が簡単になる可能性を多大に感じたのでまとめてみました。 ただ、もう少しコレがあれば...！と思う点もあったので、そこも踏まえてご紹介していきます。 ※ Auth0をちょっと知っている人向けに書くので、細かい用語の説明は入れません Auth0 Organizatio
この記事は Retty Advent Calendar 2020 10日目の記事です。 adventar.org はじめに こんばんは、最近趣味でサックス🎷 を習い始めたエンジニアの櫻井です。 ServiceMeshの話題が出てからだいぶ経ちますがそろそろ自分でも触っておきたいなと思いServiceMeshを実現するツールの1つであるIstioにチャレンジしてみました。 今回はIstioの公式サンプルであるBookinfo ApplicationにJWT(JSON Web Token)による認証・認可を入れてみます。 この認証と認可については色々調べてみたものの、あんまり参考記事を見つけることができなかったので少々梃子摺りました。（なお本記事についてはService MeshやIstioについての詳しい説明は割愛しているため、まずそれらがなんぞや？という場合にはリンクの記事を読むことをオ
Auth0、AWS東京リージョンで提供開始〜日本国内のAWSデータセンターからサービス利用が可能に〜 2つのDX（デジタルトランスフォーメーションと開発者体験）向上のための認証ソリューションを提供するAuth0株式会社（本社：東京都渋谷区、代表：ユーへニオ・ペース）は、Auth0をパブリッククラウド環境にてご利用のお客様へ、2020年12月15日よりアマゾン ウェブ サービス（以下、AWS）東京リージョン上で構築した環境にて提供開始いたしました。これにより、パブリッククラウド 環境をご利用のお客様は、これまでの米国、欧州、豪州に加え、日本国内のAWSデータセンターからサービスの利用が可能になります。 本発表について、Auth0 共同創業者CEOのユーへニオ・ペースは以下の様に述べています。 「日本企業においては企業規模に関わらずクラウドの利活用が重要であり、弊社としても高まる日本企業からの
Okta Customer Identity Cloud（旧Auth0）を活用したログイン画面のカスタマイズ方法 その２（Chat GPTも使って配色を設定してみる） 前回は、最も簡単なデザイン変更を行いましたので、今回はもう一歩踏み込んだデザイン変更をご紹介いたします。 今回参考にしたドキュメントはこちらです。 https://manage.cic-demo-platform.auth0app.com/docs/customize/universal-login-pages/customize-new-universal-login-with-the-no-code-editor 今回もダッシュボードから行えるカスタマイズですが、設定できる内容がとても多いため、まずは色の変更からご紹介いたします。 ダッシュボードのメニュー Branding -> Universal Login を開き、
調査する機会があったので、ブログにまとめてみました。 gRPCでは、データ通信にProtocol Buffersとよばれるシリアライゼーション形式を利用します。 Protocl Buffersは、データのシリアライゼーション形式として知られる一方で、シリアライズするためのスキーマ定義用として.protoファイルというインタフェース定義言語(IDL)を持っています。 実際の開発においては、この.protoファイルを先に作成することでスキーマファーストな進め方ができるのが大きな特徴です。 今回は、.protoファイルの作成～認可処理の実装～AWS環境へのデプロイまで一気通貫で紹介したいと思います。 せっかちな人へ GitHubリポジトリにすべて上げています。 構成図 ディレクトリ構成 $ tree -L 2 . ├── Dockerfile ├── go.mod ├── go.sum ├──
TC3、エンタープライズ企業の複数サービス展開における、認証認可及びID管理をつかさどる統合マネージドサービス「Tactna（タクトナ）」をアーリーアクセス版として提供開始 ギグエコノミーを活用したデジタルサービス開発を提供するTC3株式会社（以下、TC3、本社：東京都千代田区、代表取締役：須藤 義人）は、この度、スーパーアプリ構想を筆頭とした複数のアプリケーションサービスを展開する上での、アプリケーション開発とアイデンティティ・アクセス管理のギャップを埋める統合マネージドサービスとして、「Tactna（タクトナ）」をアーリーアクセスとして限定提供開始いたします。このサービスにより、多くのエンタープライズ企業におけるスーパーアプリ構想 や プラットフォーマー構想の実現を後押しします。 背景 TC3は、ウェブアプリケーション開発及び認証認可の技術バックグラウンドを活かし、Okta社のパートナ
この記事は、IDaaSアドベントカレンダー 2022の23日目の記事です。 今回はAuth0のトライアル環境の申請方法をご紹介したいと思います。 （１）申請サイトにアクセスし、メールアドレスを入力する https://auth0.com/signup （２）パスワードを設定する 1passwordなどのパスワードマネージャーを利用してパスワードを設定しましょう。 ソーシャルログインでもアカウント作成を続けることが可能です。 （３）アカウント設定を行う 引き続きフローに従い、企業で利用するのか、個人で利用するのかを選択します。 （４）トライアルのテナントが作成されました！ （３）の情報を入力し、少し待つとテナントが作成されました。左上にテナント名が記載されます。 はじめてAuth0を使う人はこの画面にある「I am a new Auth0 user」をクリックしてみましょう。 （５）Auth
ユーザーがログインして使うサービスにおいて認証・認可の仕組みを実装する際、セキュリティの観点を考慮して設計をする必要があります。設計に時間が掛かり、サービスの本質部分を開発する時間が十分に取れないこともあります。 自社開発プロダクト「SEARCH WRITE」でもログイン機能や管理機能を実装していますが、一から作る代わりに Auth0というIDaaSを導入し、セキュアな認証・認可の仕組みを比較的簡単に組み込むことで、サービス本来の価値づくりに集中できました。本番環境で1年以上運用してみた経験に基づき、Auth0のメリット・デメリット、そして導入する際の失敗談を紹介します。 Auth0とはWebアプリやモバイルアプリ、WebAPIなどに対して認証・認可の機能を提供するIDaaS(Identity as a Service)です。 IDaaSとはクラウド経由でログイン情報管理・シングルサインオ
はじめに 認証によるセキュリティの担保が大事だということは言うまでもないですが、セキュリティを万全にしようとすればするほど認証が終わるまでのハードルは高くなり、必然的にユーザー体験が落ちてしまうという結果に陥りがちです。 安全を優先するかユーザ利便性を重視するかサービス開発者にとっては悩ましいところですね。 安全性が高い認証のやり方としてMFA（Multi-factor Authentication：多要素認証）が広く使われています。ユーザー名とパスワードだけでなく、さらにもう１つ追加の検証要素を要求することで、万が一ユーザー名とパスワードが漏洩したとしても認証を突破される可能性を小さく出来る手軽な方法として普及しているようです。 ただ、このMFAも一部の人にとってはハードルが高いように思います。 と言うのはGoogle Authenticatorアプリなどを使ったMFA認証はスマホなどの
はじめに 今回はRailsのAPIモードとNext.jsを利用したSPA構成に、Auth0で認証機能をサクッと開発していきます。 Auth0は導入が簡単かつチュートリアルやドキュメントが豊富なので、初めての人でも簡単に認証機能を実装することができます。 直近で自分が行った新規開発案件でもAuth0が採用されることが多かったです。 なおAuth0についての詳しい解説は本記事では割愛するので気になった方は、こちらを確認してみてください。 またAuth0とFirebase Authenticationといった他の認証機能との比較記事はこちらで確認してみてください。 本記事で解説する内容はAuth0の公式ドキュメントに沿って解説していきます。 この記事の対象者 Next.js×Auth0で認証機能を開発したい RailsのAPIモードでAuth0の認証機能を開発したい Rails×Next.jsで
はじめに Auth0を実サービスに利用する上で欠かせない観点として「Rate Limit」というものがあります。 https://auth0.com/docs/troubleshoot/customer-support/operational-policies/rate-limit-policy Auth0には様々な観点でRate Limitが設定されており、充分に理解した上でアプリケーションの設計をしないと、ユーザーが増加してきたタイミングで障害発生に繋がる可能性があり、注意が必要です。 また、アプリに求められる要件を満たすため契約のプラン変更が必要になることもあり（契約毎に Rate Limitが異なります：参考）、その場合、根本解決までのリードタイムが長くなり得ますので、早い段階で手を打つことが重要です。 今回は、特に重要な「APIのRate Limit」についてご紹介します。 Ra
はじめに B2B向けのサービスは法人や部署のように組織単位でサービスを提供し契約を締結してもらい、その組織単位でサービスを提供するということが必要になります。Auth0ではこういったB2B向けのサービスにも認証認可機能を容易に実装できるような便利機能としてOrganizationsという機能が提供されています。 本ブログ記事ではそのOrganizations機能のご紹介と、実際にB2B向けサービス提供時に求められる主な要件でどのように活用できるかをご紹介いたします。 Auth0のOrganizations機能とは？ まずはじめに、Auth0のOrganizations機能について簡単に説明します。冒頭で説明した通り、特にB2B向けのサービスを提供する場合に、サービスを組織メンバーとして認証認可させる必要がある際に使える便利な機能です。いわゆる1つのサービスをマルチテナント型に複数の組織（法
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く