Identity Glossary

ログイン試行が信頼性の低いログインであると判断された場合にのみ、ユーザーに対してトリガーされる多要素認証（MFA）。Auth0はAdaptive MFAを使用して、正当なユーザーのログインエクスペリエンスを変えずに維持しながら、不正者に対してセキュリティを強化する必要がある場合にのみMFAをトリガーします。

Auth0のプライマリ管理者インターフェイスで、アプリケーションまたはAPIを登録し、ユーザーストアまたは別のIDプロバイダーに接続して、Auth0サービスを構成できます。

個々のユーザーがアプリケーション内の特定のオブジェクトまたはリソースにアクセスできるようにするAuth0のSaaS製品。

リソースにアクセスするためのものではなく、クライアント自体を対象とした資格情報。クライアントが解析および検証できる固定形式です。

デジタルIDを保存および管理するサービス。Auth0は、信頼できるソーシャルIDプロバイダー、エンタープライズIDプロバイダー、および法的IDプロバイダーをサポートしています。Auth0は、アプリケーションのIDプロバイダーとしても機能します。

二者間のクレームを安全に表現するための、オープンかつ業界標準のRFC 7519方法。Auth0では、IDトークンは常にJWT形式で返され、アクセストークンも多くの場合、JWT形式で返されます。JWT.ioで整形式のJWTをデコードして、クレームを表示できます。

ユーザーを認証するためのAuth0のUIウィジェット。これはそのまま使用でき、クラシックユニバーサルログインエクスペリエンスのデフォルトの顔です。Lockを使用すると、細かい動作や外観のオプションをカスタマイズできますが、その主な目的は使いやすさです。

Auth0サービスを管理し、プログラムに従って管理タスクを実行するためのAuth0のAPI。

認証プロトコルで発行される任意の数値（多くの場合、乱数または擬似乱数）で、旧式の通信を使用したリプレイ攻撃の検出と軽減に使用できます。nonceは1回しか発行されないため、攻撃者が別のnonceを使用してトランザクションを再実行しようとすると、その誤ったトランザクションをより簡単に検出できます。

認可プロトコルとワークフローを定義する認可フレームワーク。OAuth 2.0は、ロール、認可付与（またはワークフロー）、認可要求と応答、およびトークン処理を定義します。ユーザーIDを検証するOpenID Connect（OIDC）プロトコルによって、OAuth 2.0を拡張できます。

アプリケーションがユーザーのログイン情報を収集および保存することなく（したがって、ユーザーのログイン情報について責任を負わずに）、ユーザーが本人であることを確認できる認証用のオープン標準。

B2B顧客がエンドユーザーを分類し、特定のロール、ログインエクスペリエンス、およびリソースへのアクセスを定義できるようにするAuth0製品。

パスワードを使用せずに二者間で認証情報を交換できるXMLベースの標準化プロトコル。

WS-Trustを使用して信頼が確立されているシステム、ドメイン、およびIDプロバイダーの間でユーザーIDを管理するためのプロトコル。このプロトコルは主にMicrosoft製品に使用され、フェデレーションメタデータの共有方法に関するポリシーを定義します。

資格情報を1回提供するだけで、ユーザーが複数のリソースやアプリケーションにアクセスできるように、複数のプラットフォーム間でユーザーアカウントを接続すること。

Auth0実行中の特定の時点で実行される、Node.jsで記述された安全な関数。これはテナント固有であり、バージョン管理されています。アクションは、カスタムロジックでAuth0の機能をカスタマイズおよび拡張するために使用されます。

アプリケーションがAPIにアクセスするために使用できる資格情報。これは、トークンのベアラーがAPIにアクセスし、付与されたスコープで指定された特定のアクションを実行する許可を得ていることをAPIに通知します。アクセストークンは任意の形式にできますが、一般的な2つのオプションとして、不透明な文字列とJSON Webトークン（JWT）があります。これらは、HTTP認可ヘッダー内のBearer資格情報としてAPIに送信される必要があります。

認証とID管理を行うためにAuth0に依存するソフトウェア。Auth0は、シングルページ、通常のWeb、ネイティブ、およびマシンツーマシンのアプリケーションをサポートしています。

発行されたトークンに対するオーディエンスを表す一意の識別子で、JSON Webトークン内でaudクレームとして特定されたもの。オーディエンス値は、IDトークンの場合はアプリケーション（Client ID）、アクセストークンの場合は呼び出されるAPI（API Identifier）のいずれかです。Auth0では、アクセストークンの要求で送信されるオーディエンス値によって、トークンが不透明形式で返されるかJWT形式で返されるかが決まります。

特殊な名前、またはバニティ名を持つサードパーティのドメイン。CNAMEとも呼ばれます。

登録後にアプリケーションに割り当てられる識別値。この値は他のサードパーティーサービスと組み合わせて使用され、［Auth0 Dashboard］ > ［Application Settings（アプリケーション設定）］で確認できます。

クライアント（アプリケーション）が認可サーバーで認証するために使用するシークレット。これはクライアントと認可サーバーだけが知っているものであり、推測できないように十分にランダムである必要があります。

セキュリティトークンにパッケージ化される属性で、トークンのプロバイダーがエンティティに関して行っているクレームを表します。

1人以上のユーザーのセット。Auth0認可拡張機能では、グループを使用して、一度に多くのユーザーにアクセスを許可します。

認証後にAuth0が応答を送信する先のURL。多くの場合、認証後にユーザーがリダイレクトされるURLと同じです。

各テナントで使用できる機能や割り当てを定義する契約。Auth0には、さまざまな開発者や組織のニーズを満たすために複数のサブスクリプションレベルがあります。

対象の機能または動作がプラットフォームから削除されることを示す製品リリース段階。その機能または動作を続けて使用すると、おそらくエラーが発生します。新しい動作は、移行期間中にオプトインしなかったテナントに対して自動的に有効になります。

機能または動作へのアクセスがプラットフォームから削除される日付。サポート終了日は、プランのタイプによって異なる場合があります。

リモートアプリケーションにアクセスする必要があるユーザーを個別に、ローカルディレクトリからリモートディレクトリに手動でプロビジョニングする（実質的に元のアカウントのコピー、すなわちシャドーを作成する）、継続するのが困難な方法。

ユーザーが1つのアプリケーションにログインした後、そのユーザーが使用しているプラットフォーム、テクノロジー、ドメインに関係なく、そのユーザーを他のアプリケーションに自動的にログインさせるサービス。ユーザーは1回だけサインインします（これがこの機能の名前の由来です）。同様に、シングルログアウト（SLO）は、ユーザーが1つのアプリケーションからログアウトした後、ログインしていた各アプリケーションまたはサービスからログアウトされるときに発生します。SSOとSLOはセッションを使用することで可能になります。

アプリケーションが実行できる特定のアクション、またはユーザーに代わってアプリケーションが要求できる情報を定義するメカニズム。多くの場合、アプリケーションは、オンラインリソースですでに作成されている情報を利用しようとします。そのためには、アプリケーションはユーザーに代わってこの情報にアクセスするための認可を求める必要があります。アプリが認可サーバー経由でリソースへのアクセス許可を要求する場合、そのアプリはスコープパラメーターを使用して必要なアクセスを指定し、認可サーバーはスコープパラメーターを使用して実際に付与されたアクセスで応答します。

ユーザーが正常に認証されたことを証明するために使用される、デジタル署名されたアーティファクト。

受信しているトークンが署名され、有効であり、信頼できるソース（IDプロバイダー）からのものであることをミドルウェアが確認した後に、ミドルウェアによって発行されるエンティティ。このエンティティは、IDプロバイダーによる認証が成功したという事実を表します。クッキーが存在する限りユーザーが認証されているとみなされるため、トークンを使用したこのプロセスを継続的に繰り返す必要がなくなります。

ユーザーの中央リポジトリ（最もよく知られているのはActive Directory）。資格情報と属性を一元管理できるため、各アプリケーションがそれぞれ独自のローカルID設定やユーザーのプールを持つ必要がなくなります。同じユーザーディレクトリを使用するすべてのアプリケーションに対し、シングルサインオンできます。

特定のアプリケーションによって提供される機能のコンテキストで特定のユーザーを定義する属性のセット。

トークン内の情報を改ざんから保護する暗号化された文字列。これらの情報が変更または改ざんされると、署名は検証できなくなり、拒否されます。

Auth0では、単一のソフトウェアインスタンスに対して特定の権限があるアクセスを共有する、論理的に分離されたユーザーのグループのこと。複数のテナントが同じマシン上で実行している場合でも、その中の1つのテナントが別のテナントのデータにアクセスすることはできません。一般に、テナントは、ソフトウェアマルチテナントアーキテクチャから借用された用語です。

プログラムに従ってトークンを要求するために使用される認可サーバー上のエンドポイント。

ユーザーのログインなどの特定の操作が実行時に発生したときに、アクションを自動的に呼び出すイベント。複数のトリガーが同時に実行され、関与するフローをブロックするものもありますが、同時には実行されないものもあります。

最初の要素がパスワードではない認証の形式。代わりに、メールやSMS、プッシュ通知、または生体認証センサーで受信したワンタイムパスワードを使用できます。パスワードレスではワンタイムパスワードが使用されるため、ユーザーは従来のユーザー名/パスワードによるログインに比べて、一般的なパスワードベースの攻撃（辞書や資格情報のスタッフィングなど）の影響を受けにくくなります。

サードパーティのWebサイトまたはアプリでのデータ漏洩で侵害されたユーザー名とパスワードの組み合わせをユーザーが使用した場合に、Auth0がユーザーに通知する攻撃防御の形式。

OAuth 2.0プロトコルによると、クライアント（アプリケーション）は、資格情報（クライアントIDやシークレットなど）を安全に保持できるかどうかに応じて、機密またはパブリックに分類できます。パブリッククライアントは資格情報を安全に保持できないため、クライアントシークレットの使用を必要としない付与タイプのみを使用する必要があります。パブリッククライアントに発行されたIDトークンは、秘密鍵（RS256）を使用して非対称に署名され、トークンの署名に使用された秘密鍵に対応する公開鍵を使用して検証される必要があります。

アクションを使用して拡張できるプロセス。各フローはそれぞれ1つ以上のトリガーで構成され、Auth0手順の単一ポイント中に情報が移動する論理パイプラインを表します。

一般提供（GA）版に先立って、対象の機能または動作がサブスクライバーに提供され、最終的なフィードバックを提供しながら新製品の機能を吟味して導入する時間を与える、製品リリース段階。機能面では、完全なコードが使われ、安定しており、さまざまなシナリオで役立ちます。また、GA版における品質の期待に応えている、またはほぼ応えていると考えられます。ベータ版は、選ばれた一握りのサブスクライバーに制限することも（プライベート）、すべてのサブスクライバーに提供することもできます（パブリック）。

Auth0がログインプロセス中にCAPTCHAを有効にすることで、疑わしいボットトラフィックをブロックする攻撃防御の形式。

環境設定やプロファイル設定など、ユーザーが更新できる情報。メタデータはIDトークンに追加され、ユーザープロファイルに保存できます。

要求元のリソースへのアクセスを削除または復元すること。Auth0の攻撃防御スイートの機能（侵害されたパスワードの検出、ブルートフォース保護、不審なIPのスロットリング）を指します。各サービスはログイン/サインアップの傾向を評価し、疑わしいアクティビティに関連付けられたIPアドレスをブロックします。

Auth0による認証フローの実装で、これは認可サーバーの主要な機能です。ユーザーの本人証明が必要になるたびに、アプリケーションはユニバーサルログインにリダイレクトされ、Auth0がユーザーのアイデンティティを保証するために必要な処理を行います。

保護されたリソースをホストするサーバー。リソースサーバーは保護されたリソースの要求を受け入れ、応答します。

保護されたリソースへのアクセスを許可できるエンティティ（ユーザーやアプリケーションなど）。

更新されたアクセストークンを取得するために使用できる特殊なトークン。これは、ユーザーに再度ログインを強いることなく、期限切れになるアクセストークンを更新する場合に便利です。リフレッシュトークンを使用すると、リフレッシュトークンがブロックリストに登録されるまで、いつでも新しいアクセストークンを要求できます。

脆弱性を最小限に抑えるためにリフレッシュトークンを頻繁に置き換える戦略。リフレッシュトークンのローテーションを使用すると、アプリケーションがリフレッシュトークンを交換して新しいアクセストークンを取得するたびに、Auth0も新しいリフレッシュトークンを返します。

新しいユニバーサルログインエクスペリエンスをサポートされている言語でレンダリングできる機能。

ユーザーがシステムに対して必要とするアクセスのレベルを示す、ユーザーに割り当てられるユーザーアイデンティティのアスペクト。ロールは基本的に権限の集合です。

対象の機能または動作が完全に機能し、（価格レベルによって制限される）すべてのサブスクライバーが本番環境で使用できる製品リリース段階。新しいリリースが既存の機能を置き換える場合、Auth0は弊社の廃止ポリシーに従って下位互換性の期間を提供し、新しいリリースの導入時間を確保できるよう、お客様に通知します。

非常に多くのアカウントをターゲットにした、単一IPアドレスからの不審なログインからテナントを保護する攻撃防御の形式。

脅威アクターとも呼ばれます。害を及ぼす意図をもってビジネスまたは環境に脅威を与えるエンティティ（個人またはグループ）。データセンターへの侵入から、盗まれた資格情報によるシステムへのハッキングまで、被害には物理的およびサイバー上の損害が含まれる可能性があります。

IDプロバイダーや認証局がユーザーについて言及することをリソースが前向きに信じる場合、そのリソースはそのIDプロバイダーまたは認証局を信頼しています。

ディレクトリ、そのすべてのユーザー、およびそのディレクトリを使用するすべてのアプリケーションを囲む一連の境界。一部の実装では、この境界は物理的な場所を指します。また、VPNを介して接続された一連のネットワークまたはデバイスを指す場合もあります。

複数の要素を考慮した認証プロセス。通常、Auth0では、最初の要素は標準のユーザー名/パスワード交換であり、2番目の要素はメールまたはSMS経由のコードまたはリンク、AuthyやGoogle Authenticatorなどのアプリ経由ワンタイムパスワード、あるいはGuardianやDuoなどの電話アプリ経由のプッシュ通知です。複数の要素を使用することで、パスワードが他人の手に渡ったり、携帯電話が盗まれたりするなど、いずれかの要素が誰かに取得された場合でも、アカウントの安全性を保つことができます。

対象の機能または動作が新規サブスクライバーによる使用をサポートしていないことに加え、積極的な強化が行われおらず、かつ最小限のメンテナンスしか行われていないことを示す製品リリース段階。廃止の時点でその機能または動作を使用していたテナントは、引き続きアクセスできます。

Auth0と、アプリケーションのユーザーのソースとの関係。例として、IDプロバイダー（GoogleやActive Directoryなど）、パスワードレス認証方法、ユーザーデータベースなどがあります。

ブルートフォース保護、不審なIPのスロットリング、侵害されたパスワードの検出、ボット検知、Adaptive Multi-factor Authenticationなど、攻撃を検出して軽減するためにAuth0が提供する機能。

対象の機能や動作が限られた数のサブスクライバーまたは顧客開発パートナー（CDP）に提供され、それらのサブスクライバーまたはCDPがテストを行い、今後の機能に関するフィードバックを返すことができる製品リリース段階。この段階では、機能がまだ完成していない可能性がありますが、検証はできます。

リソースがユーザーのアイデンティティを確認できるようにする、ユーザーとリソースの間で合意された共有シークレットまたは一連の情報。

OAuth 2.0プロトコルによると、クライアント（アプリケーション）は、資格情報（クライアントIDやシークレットなど）を安全に保持できるかどうかに応じて、機密またはパブリックに分類できます。機密クライアントは、資格情報を無許可の当事者に公開することなく安全な方法で保持でき、そのためには信頼できるバックエンドサーバーが必要です。これらのクライアントは、トークンエンドポイントを呼び出すときにクライアントIDとシークレットを指定して認証しなければならない付与タイプを使用でき、対称または非対称に署名されたトークンを発行させることができます。

クライアントが開始するバックチャネル認証フローで、ユーザーがサービスを利用するのに役立つデバイス。

攻撃者がクライアントまたはサービスを騙してアクションを実行させる状況。

Auth0が知る範囲で、Auth0プラットフォームと顧客アプリケーションの相互運用に障害をきたす、Auth0プラットフォームへの変更。

顧客が特定の機能や動作から離れるプロセス。移行は、製品リリースの廃止段階で行う必要があります。

単一のIPアドレスから発生し、単一のユーザーアカウントをターゲットとする総当たり攻撃から保護する攻撃防御の形式。

トークンが不正者によって改ざんされないように、トークンにデジタル署名するためのハッシュアルゴリズム。

Auth0が製品機能をどのように計画、リリース、廃止するかを説明するフェーズ。製品機能はすべてのリリース段階を経て進行するとは限らず、各段階の期間は機能のスコープや影響力によって異なります。

ユーザーを認証するためにサードパーティーのIDプロバイダーに依存するエンティティ（サービスやアプリケーションなど）。

認可サーバーによって生成され、認可応答の一部としてアプリケーションに返されるランダムな文字列。認可コードの有効期間は比較的短く、認可コードフローの使用時に（Proof Key for Code Exchange（PKCE）の有無にかかわらず）トークンエンドポイントでアクセストークンと交換されます。

ユーザーによるアクセスの限界を定義するために使用される集中管理型サーバー。たとえば、認可サーバーは、ユーザーが利用できるデータ、タスク、機能を制御できます。認可サーバーによってユーザーが認証されることはありません。ユーザーの身元を確認するのは認証サーバーの役割です。

OAuth 2.0で概説されている認可付与の別名。認可フローは、リソース（アプリケーションまたはAPI）が要求元にアクセスを許可するために使用するワークフローです。テクノロジーのタイプ（たとえば、アプリケーションがクライアントシークレットを保存できる場合）と要求元のタイプに基づいて、リソース所有者は認可コードフロー、Proof of Key Code Exchange（PKCE）、Resource Owner Password Credential（ROPG）、暗黙フロー、またはクライアントの資格情報を使用できます。

ユーザーのアイデンティティを確認または拒否するサーバー。認証サーバーによって、ユーザーが利用できるアクションやリソースが制限されることはありません（ただし、この目的でコンテキストを提供することは可能）。

クライアントが開始するバックチャネル認証フロー内。