みなさま、認可の設計に苦しんでいるでしょうか？私は苦しんでいます。苦しまなかった瞬間などありません。昔「アプリケーションにおける権限設計の課題」を執筆しましたが、あれから3年以上が経ちます。 当時は認可の設計に関する情報がうまくまとまっている記事などほとんど無く、調べに調べて得たナレッジを書き記したのが上記の記事です。3年以上経ちますが、苦悩が今も特に変わっていないことが驚きです。 ただし、世の中的には認可のライブラリであったりサービスというのは少しずつ増えてきている印象があります(Auth0の OpenFGA であったりOsoの Oso Cloud 、Asertoの Topaz )。 認可の設計に関する記事も少しずつ増えている印象があり、その中でも本記事で紹介したいのがAuthorization Academyです。 これは認可サービスである Oso Cloud やOSSのライブラリ o
Auth0にPassKeyが搭載されたぞ！！！
はじめに 先日ふと Auth0 のダッシュボードを眺めていると、興味深い項目が表示されていました。 Passkey がある!!! なので、今回は Auth0 に搭載されたパスワードレス認証方式である Passkey の説明をしていきます。 なお、Auth0 の設定方法についてはAuth0 からリリースされた記事を参考にして、記載しています。 パスワード認証の課題 Passkey の説明をするまえに、パスワード認証の課題について見ていきます。 認証方法として当然とされているパスワード認証ですが、以下の 3 つの課題を持っています。 ① パスワードの使い回し ② 推測されやすいパスワードの使用 ③ フィッシングアプリへのパスワード入力 それぞれ見ていきましょう。 ① パスワードの使い回し ログインが必要なアプリにはそれぞれ異なるパスワードを使用するというのは皆さんご存知だとは思います。 とはい
TC3、エンタープライズ企業の複数サービス展開における、認証認可及びID管理をつかさどる統合マネージドサービス「Tactna（タクトナ）」をアーリーアクセス版として提供開始 | TC3株式会社｜GIG INNOVATED.
TC3、エンタープライズ企業の複数サービス展開における、認証認可及びID管理をつかさどる統合マネージドサービス「Tactna（タクトナ）」をアーリーアクセス版として提供開始 ギグエコノミーを活用したデジタルサービス開発を提供するTC3株式会社（以下、TC3、本社：東京都千代田区、代表取締役：須藤 義人）は、この度、スーパーアプリ構想を筆頭とした複数のアプリケーションサービスを展開する上での、アプリケーション開発とアイデンティティ・アクセス管理のギャップを埋める統合マネージドサービスとして、「Tactna（タクトナ）」をアーリーアクセスとして限定提供開始いたします。このサービスにより、多くのエンタープライズ企業におけるスーパーアプリ構想 や プラットフォーマー構想の実現を後押しします。 背景 TC3は、ウェブアプリケーション開発及び認証認可の技術バックグラウンドを活かし、Okta社のパートナ
Auth0️で実装する｜ユーザー体験を向上するEmailのみでのシンプルなパスワードレス認証 | TC3株式会社｜GIG INNOVATED.
はじめに 認証によるセキュリティの担保が大事だということは言うまでもないですが、セキュリティを万全にしようとすればするほど認証が終わるまでのハードルは高くなり、必然的にユーザー体験が落ちてしまうという結果に陥りがちです。 安全を優先するかユーザ利便性を重視するかサービス開発者にとっては悩ましいところですね。 安全性が高い認証のやり方としてMFA（Multi-factor Authentication：多要素認証）が広く使われています。ユーザー名とパスワードだけでなく、さらにもう１つ追加の検証要素を要求することで、万が一ユーザー名とパスワードが漏洩したとしても認証を突破される可能性を小さく出来る手軽な方法として普及しているようです。 ただ、このMFAも一部の人にとってはハードルが高いように思います。 と言うのはGoogle Authenticatorアプリなどを使ったMFA認証はスマホなどの
Auth0 Rate Limit完全ガイド：サービスの安定性を保つための重要ポイント | TC3株式会社｜GIG INNOVATED.
はじめに Auth0を実サービスに利用する上で欠かせない観点として「Rate Limit」というものがあります。 https://auth0.com/docs/troubleshoot/customer-support/operational-policies/rate-limit-policy Auth0には様々な観点でRate Limitが設定されており、充分に理解した上でアプリケーションの設計をしないと、ユーザーが増加してきたタイミングで障害発生に繋がる可能性があり、注意が必要です。 また、アプリに求められる要件を満たすため契約のプラン変更が必要になることもあり（契約毎に Rate Limitが異なります：参考）、その場合、根本解決までのリードタイムが長くなり得ますので、早い段階で手を打つことが重要です。 今回は、特に重要な「APIのRate Limit」についてご紹介します。 Ra
Okta CIC (Auth0) Enterprise Connectionsを活用した外部IdP（SAML, OpenID Connect）認証設定ガイド | TC3株式会社｜GIG INNOVATED.
Okta CIC (Auth0) Enterprise Connectionsを活用した外部IdP（SAML, OpenID Connect）認証設定ガイド はじめに Okta CIC(Auth0)管理画面における認証関連設定項目 Okta CIC（Auth0）の認証方法(connection)は複数種類があります。例えば、ユーザー名/パスワードをAuth0に登録した上でログインする方法はDatabase Connectionsです。その他にも、Googleアカウントからの認証を実現するのであればSocial Connectionsがあります。Passwordless Connectionsについては以前のブログ記事にてご紹介しました。 このように様々な認証方法に対応していますが、本記事では、Enterprise Connectionsを利用した外部IdPを活用した認証をご紹介します。接続
Okta Customer Identity Cloud（Auth0）におけるCloudWatch Logsを活用したログ監視方法のご紹介 | TC3株式会社｜GIG INNOVATED.
Okta Customer Identity Cloud（Auth0）におけるCloudWatch Logsを活用したログ監視方法のご紹介 はじめに Okta Customer Identity Cloud（powered by Auth0）は、開発者が認証機能を実装するには非常に簡単なツールではありますが、Okta CICの構築において忘れられがちなのは運用後の設計です。 Auth0は認証に関するログや管理者の操作などのログをAuth0内で管理してくれますが（参考）、プランによってログの保管期間が決まっています（参考）。エンタープライズプランであっても30日が保存の上限期間となっているため、30日を超える期間ログを保存しておきたい場合にはLog Streaming機能を使うことで（Essentialプラン以上が必要です）、AWS S3に格納するなどのことが必要です。前回はその設定をTer
本稿はJCB Tech Blog Advent Calendar 2022の12月25日の記事です。 JCBデジタルソリューション開発部アーキテクトチームの長沼です。 JDEPではID管理にOktaを利用しており、 開発者のID管理をOkta Workforce Identity Cloud、アプリ利用者のID管理をOkta Customer Identity Cloud（旧Auth0、以下CIC） と使い分けています。 今回はSingle Page Application（以下SPA）からCICを使うためのクライアントライブラリであるSPA SDKで面白い気づきがありましたので、ご紹介したいと思います。 TL;DR SPA SDKを用いてログイン画面を呼び出すメソッドは2種類あり、 リダイレクト（画面遷移）によるloginWithRedirectと、ポップアップ（別ダイアログ表示）による
Enterprise Connectionを設定してAuth0での認証をAzure Active Directoryと統合してみた | DevelopersIO
Enterprise Connectionを設定してAuth0での認証をAzure Active Directoryと統合してみた こんにちは、CX事業本部 IoT事業部の若槻です。 Auth0では、Enterprise Connectionを設定することにより、外部のEnterprise Identity Providers上で管理されているIDを使用してAuth0アプリケーションへのログインが可能（統合認証）とすることが出来ます。 Enterprise Identity Providers これにより例えば、既にある認証基盤のログイン情報をAuth0アプリケーションでもユーザーに利用させられるため、ユーザーエクスペリエンスの改善が期待できます。 今回は、Enterprise Connectionを設定してAuth0での認証をMicrosoft Azure Active Director
third party cookies(サードパーティクッキー)をブロックしたブラウザでアクセストークンを取得する – 【Auth0】
以下２点を変更します。 トークンの保管場所をin memoryからlocalstorageに変更する リフレッシュトークンローテーションを使用する FireFoxの設定 FireFoxでthird party cookies(サードパーティクッキー)をブロックします。 これでブラウザの設定はOKです。 トークンの保管場所をin memoryからlocalstorageに変更する auth0Client = await auth0.createAuth0Client({ domain: config.domain, clientId: config.clientId, authorizationParams: { audience: config.audience, // API Identifier redirect_uri: config.callbackUrl, // callback
Auth0でSingleSignOnに対応してみる
はじめに ZENKIGEN（ゼンキゲン） で revii（リービー）の開発・運用をしているmikan（みかん）です。 今回はユーザー認証基盤「Auth0」について紹介したいと思います。 ユーザー登録やログインといったユーザー認証機能は toB 向けのサービスには必須の要件ですが、これまではサービスごとに自前で実装することが多かったのではないでしょうか？ しかし、それだと同じような機能なのに使用するプログラミング言語に合わせてゼロから実装する必要があるだけでなく、多要素認証などに対応するのも一苦労です。 そのため、近年ではFirebase AuthenticationやAmazon Cognitoなどユーザー認証基盤を切り出した IDaaS（Identity as a Service）が現れてきましたが、その中でも Auth0 はユーザー認証基盤に特化しておりカスタマイズも豊富です。 一方で
はじめに この記事はAuth0を使ってSAML Service ProviderとIdentity Providerの環境を構築する手順です。Auth0はSAML SP/IdPのどちらでも機能することが可能で様々なSAMLのユースケースに対応できます。 検証環境 OS : macOS Catalina 10.15.2 node : 10.15.3 npm : 6.13.2 手順 IdP側その1 Auth0のダッシュボードから"Create tenant"を選択して新しいIdP用のテナントを作成します。 左ペインの"Applications"をクリックして右上の"CREATE APPLICATION"を押します。 "Name"に任意の名前を入力して"Choose an application type"で"Regular Web Applications"を選択して"CREATE"を押します
開発環境で、ReactアプリケーションでAuth0を使って認証機能を追加しました。 その時、Auth0のApplication URIsのApplication Login URIの設定で少しハマりましたので、ちょっとしたことですが解決方法を残します。※2021年10月31日時点の情報です。 Application Login URIはhttpsにする Reactアプリケーションの開発環境のURLは http://localhost:3000 に設定していました。おそらくデフォルトだと思います。 ですので、Auth0のApplication Login URIに http://localhost:3000 を設定しようとしたのですが、エラーになりました。エラーメッセージによるとhttpsにしてくれとのこと。 Error!Payload validation error: 'Object d
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
認可のアーキテクチャに関する考察（Authorization Academy IIを読んで）
ログイン画面表示方法の違いは思った以上に大きかった件 - JCB Tech Blog
Auth0でSAML SP/IdPを構築する - Qiita
開発環境でAuth0を使う際にApplication Login URIの設定でハマった